MP3 files ripped from my CD collection (and .m4a files from iTunes) will play fine. The .aif files from the HDTracks sampler also play.
Is there something special about those ogg files?
The file I've been trying (an opera) was generated by ripping one file apiece from 2 CDs and then merging those files. I think I did the original rip and encode (to flac, at the time) using JRiver MC19. This results in somewhat large files, but not terribly so (470,093 KB). They play fine within JRiver itself and there's no problem with the "Generic DLNA" server transcoding them into MP3.
If there is a way to extract information that would be helpful to you from the Ogg files, please let me know.
You are probably exceeding the maximum file size for a transcoding to wave which is 2gb IIRC.
Does the PCM w/o header ply for you on smaller files?
Out of curiosity, since I may have to end up using it, what encode rate does your DLNA server use for "high-quality" MP3 streaming? Given the 2GB limit (if that indeed turns out to be the issue), are there any other options for streaming large files?
Hmm... having Audacity re-export to 16-bit PCM results in a 1.68 GB file (1,807,286,252 bytes). So, I could see how 24-bit PCM exceeds 2GB. (BTW, there seems to be some ambiguity on the interwebs regarding whether the WAV header makes use of a signed or unsigned number, and thus whether the limit is 2GB or 4GB.)All DLNA compliant devices are required to play 16-bit PCM headerless (aka L16).
I think I tried changing the Audiophile DAC settings to 16-bit PCM as well, but encountered the same, no-playback problem. I'll have to try that again; based on the Audacity re-export, it seems like streaming 16-bit PCM should not hit the 2GB limit.
I'll give other files a try when I return home this evening.
Out of curiosity, since I may have to end up using it, what encode rate does your DLNA server use for "high-quality" MP3 streaming? Given the 2GB limit (if that indeed turns out to be the issue), are there any other options for streaming large files?
Thanks,
Matt
Does the PCM w/o header play for you on smaller files?
No, 24-bit PCM playback even on fairly short ogg files (31 MB, 18min duration) experiencethe same problem.
No, 24-bit PCM playback even on fairly short ogg files (31 MB, 18min duration) experience the same problem. Looking at the Media Network log, just 44 bytes gets transferred for each DLNA GET from the receiver, and I don't see how those files should come anywhere close to the 2GB WAV limit.Right click on the file in your library, library tools, convert format. Change the bitdepth to 24. See if the conversion works (testing conversion vs serving the file).
Any other thoughts?
Thanks,
Matt
Right click on the file in your library, library tools, convert format. Change the bitdepth to 24. See if the conversion works (testing conversion vs serving the file).
PCM L16 (no header) works for both the large and small ogg files.
This should work adequately for my needs, although it would be interesting to know why the 24-bit streaming of ogg files won't work. I do have one other question, though...I'd like to try and track this down more closely.
The Yamaha RX-A1040 and JRiver's DNLA server occasionally get into a mode in which switching to a new track/song has a moment of initial static (or pops) before successful playback begins. In other threads on this forum, I've seen the static attributed to mis-interpretation of the header/tags for a file. Why is the problem occurring with L16 (no header), though? Is there anything I can do to prevent this static?
I'd like to try and track this down more closely.
First for the 24 bit streaming of ogg files.
The small file that you tested, what is the original sample rate and channel count?
In your MC DLNA server conversions settings, are you using "Specified Format" ? and under Advanced, sample rate setting is "same as source"? Stereo Downmix on or off?
As for the static, I've occasionally run across that as well but haven't pinned it down. Can you make it consistently happen, perhaps with a specific track? If you right click on the zone and under DLNA controller options, disable SetNext support does it still happen?
If you right click on the zone and under DLNA controller options, disable SetNext support does it still happen?
My experimentation has been limited (about 10 minutes of switching tracks), but disabling SetNext appears to have resolve the issue!Our use of SetNextAVTransportURI depends on the proper functioning of GetMediaInfo. You might want to let them know that.
How should I present this deficiency to Yamaha (as it seems like something a firmware update could resolve, since little of DLNA/UPnP stack should be hardcoded)?
It would be interesting if you downloaded UPnP Tools for Developer and ran the device spy to see if your Yamaha claims to support the SetNextAVTransportURI function.
<root>
<yamaha:X_device>
<yamaha:X_URLBase>http://10.0.0.79:80/</yamaha:X_URLBase>
<yamaha:X_serviceList><yamaha:X_service>
<yamaha:X_specType>urn:schemas-yamaha-com:service:X_YamahaRemoteControl:1</yamaha:X_specType>
<yamaha:X_controlURL>/YamahaRemoteControl/ctrl</yamaha:X_controlURL>
<yamaha:X_unitDescURL>/YamahaRemoteControl/desc.xml</yamaha:X_unitDescURL>
</yamaha:X_service></yamaha:X_serviceList></yamaha:X_device>
<specVersion>
<major>1</major>
<minor>0</minor>
</specVersion>
<device ms:X_MS_SupportsWMDRM="true">
<dlna:X_DLNADOC>DMR-1.50</dlna:X_DLNADOC>
<pnpx:X_compatibleId>MS_DigitalMediaDeviceClass_DMR_V001
</pnpx:X_compatibleId><pnpx:X_deviceCategory>MediaDevices Multimedia.DMR MediaDevice.DMC
</pnpx:X_deviceCategory><pnpx:X_hardwareId>VEN_0033&DEV_0006&REV_01
</pnpx:X_hardwareId><df:X_deviceCategory>Multimedia.DMR
</df:X_deviceCategory>
<deviceType>urn:schemas-upnp-org:device:MediaRenderer:1</deviceType>
<friendlyName>RX-A1040 B536C5</friendlyName>
<manufacturer>Yamaha Corporation</manufacturer>
<manufacturerURL>http://www.yamaha.com/</manufacturerURL>
<modelDescription>AV Receiver</modelDescription>
<modelName>RX-A1040</modelName>
<modelNumber>A1040</modelNumber>
<modelURL>http://www.yamaha.com/</modelURL>
<serialNumber>00689AA3</serialNumber>
<UDN>uuid:5f9ec1b3-ed59-1900-4530-00a0deb536c5</UDN>
<UPC>123810928305</UPC>
<iconList>
<icon><mimetype>image/jpeg</mimetype><width>48</width><height>48</height><depth>24</depth><url>/BCO_device_sm_icon.jpg</url></icon>
<icon><mimetype>image/jpeg</mimetype><width>120</width><height>120</height><depth>24</depth><url>/BCO_device_lrg_icon.jpg</url></icon>
<icon><mimetype>image/png</mimetype><width>48</width><height>48</height><depth>24</depth><url>/BCO_device_sm_icon.png</url></icon>
<icon><mimetype>image/png</mimetype><width>120</width><height>120</height><depth>24</depth><url>/BCO_device_lrg_icon.png</url></icon>
</iconList><serviceList>
<service>
<serviceType>urn:schemas-upnp-org:service:RenderingControl:1</serviceType>
<serviceId>urn:upnp-org:serviceId:RenderingControl</serviceId>
<SCPDURL>/RenderingControl/desc.xml</SCPDURL>
<controlURL>/RenderingControl/ctrl</controlURL>
<eventSubURL>/RenderingControl/evt</eventSubURL>
</service>
<service>
<serviceType>urn:schemas-upnp-org:service:ConnectionManager:1</serviceType>
<serviceId>urn:upnp-org:serviceId:ConnectionManager</serviceId>
<SCPDURL>/ConnectionManager/desc.xml</SCPDURL>
<controlURL>/ConnectionManager/ctrl</controlURL>
<eventSubURL>/ConnectionManager/evt</eventSubURL>
</service>
<service>
<serviceType>urn:schemas-upnp-org:service:AVTransport:1</serviceType>
<serviceId>urn:upnp-org:serviceId:AVTransport</serviceId>
<SCPDURL>/AVTransport/desc.xml</SCPDURL>
<controlURL>/AVTransport/ctrl</controlURL>
<eventSubURL>/AVTransport/evt</eventSubURL>
</service>
</serviceList>
<presentationURL>http://10.0.0.79/</presentationURL>
</device>
</root>
<action>
<name>SetNextAVTransportURI</name>
<argumentList>
<argument>
<name>InstanceID</name>
<direction>in</direction>
<relatedStateVariable>A_ARG_TYPE_InstanceID</relatedStateVariable>
</argument>
<argument>
<name>NextURI</name>
<direction>in</direction>
<relatedStateVariable>NextAVTransportURI</relatedStateVariable>
</argument>
<argument>
<name>NextURIMetaData</name>
<direction>in</direction>
<relatedStateVariable>NextAVTransportURIMetaData</relatedStateVariable>
</argument>
</argumentList>
</action>
Bump.
Bob, did you ever get the chance to look into this hiccup with Ogg Vorbis -> 24-bit PCM conversion (only when streaming)?
Thanks!
Matt
Yes. I tried it with 2 hardware renderers that can play 24 bit files natively.
On a WDTV Live. It played fine (changing the sample rate to 48k on the fly, wanted to find out if that made a difference).
The other device, a Raumfeld Speaker S, leaving the sample rate same as source, also played back fine.
I'm thinking the fact that it stops right away (which causes the truncated file) means it can't deal with the file for some reason or another.
A wireshark trace may help. Perhaps your renderer is requesting past the end of the converted file.
Try pulling the file url (when it tries to play on the renderer you can get the URL from MC's status display).
Use a browser or wget.
<?xml version="1.0" encoding="UTF-8" ?><s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<s:Body>
<u:SetAVTransportURI xmlns:u="urn:schemas-upnp-org:service:AVTransport:1">
<InstanceID>0</InstanceID>
<CurrentURI>http://10.0.0.3:52100/Music/F174131.wav</CurrentURI>
<CurrentURIMetaData><DIDL-Lite xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/" xmlns:dlna="urn:schemas-dlna-org:device-1-0" xmlns:av="urn:schemas-sony-com:av" xmlns:pv="http://www.pv.com/pvns/">
<item id="F174131" parentID="0" restricted="1">
<dc:title>La Finta Giardiniera</dc:title>
<upnp:class>object.item.audioItem.musicTrack</upnp:class>
<upnp:playbackCount>25</upnp:playbackCount>
<dc:date/>
<pv:rating>5</pv:rating>
<pv:playcount>25</pv:playcount>
<pv:lastPlayedTime>2014-10-21T21:26:13</pv:lastPlayedTime>
<pv:addedTime>1371954919</pv:addedTime>
<pv:modificationTime>1372986361</pv:modificationTime>
<upnp:albumArtURI dlna:profileID="JPEG_SM">http://10.0.0.3:52100/AArs/174131.jpg</upnp:albumArtURI>
<upnp:albumArtURI dlna:profileID="JPEG_TN">http://10.0.0.3:52100/AArt/174131.jpg</upnp:albumArtURI>
<res protocolInfo="http-get:*:audio/wav:DLNA.ORG_PN=WAV;DLNA.ORG_OP=01;DLNA.ORG_CI=0;DLNA.ORG_FLAGS=01700000000000000000000000000000" duration="2:50:45.000" size="44" nrAudioChannels="2" sampleFrequency="44100" bitsPerSample="24">http://10.0.0.3:52100/Music/F174131.wav</res>
<res protocolInfo="http-get:*:image/jpeg:DLNA.ORG_PN=JPEG_SM;DLNA.ORG_OP=00;DLNA.ORG_CI=1">http://10.0.0.3:52100/ARrs/174131.jpg</res>
<res protocolInfo="http-get:*:image/jpeg:DLNA.ORG_PN=JPEG_TN;DLNA.ORG_OP=00;DLNA.ORG_CI=1">http://10.0.0.3:52100/ARrt/174131.jpg</res>
</item>
</DIDL-Lite>
</CurrentURIMetaData>
</u:SetAVTransportURI>
</s:Body>
</s:Envelope>
Looking at the SetAVTransportURI() invocation (which I'll post below), the URL for the long Ogg Vorbis file (per the descriptions way back at the start of this thread) isHard to square that with my results which were that it played fine.
http://10.0.0.3:52100/Music/F174131.wav
Giving that URL to Chrome, it happily opens its embedded player and then proceeds to immediately stop. Picking an MP3 file that plays fine through the Audiophile DAC, such as
http://10.0.0.3:52100/Music/F8145.wav
Chrome proceeds to play it without issue (as does the renderer).
Offhand, it seems like there is something askew with the F174131.wav converted stream.Code: [Select]<?xml version="1.0" encoding="UTF-8" ?><s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<s:Body>
<u:SetAVTransportURI xmlns:u="urn:schemas-upnp-org:service:AVTransport:1">
<InstanceID>0</InstanceID>
<CurrentURI>http://10.0.0.3:52100/Music/F174131.wav</CurrentURI>
<CurrentURIMetaData><DIDL-Lite xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/" xmlns:dlna="urn:schemas-dlna-org:device-1-0" xmlns:av="urn:schemas-sony-com:av" xmlns:pv="http://www.pv.com/pvns/">
<item id="F174131" parentID="0" restricted="1">
<dc:title>La Finta Giardiniera</dc:title>
<upnp:class>object.item.audioItem.musicTrack</upnp:class>
<upnp:playbackCount>25</upnp:playbackCount>
<dc:date/>
<pv:rating>5</pv:rating>
<pv:playcount>25</pv:playcount>
<pv:lastPlayedTime>2014-10-21T21:26:13</pv:lastPlayedTime>
<pv:addedTime>1371954919</pv:addedTime>
<pv:modificationTime>1372986361</pv:modificationTime>
<upnp:albumArtURI dlna:profileID="JPEG_SM">http://10.0.0.3:52100/AArs/174131.jpg</upnp:albumArtURI>
<upnp:albumArtURI dlna:profileID="JPEG_TN">http://10.0.0.3:52100/AArt/174131.jpg</upnp:albumArtURI>
<res protocolInfo="http-get:*:audio/wav:DLNA.ORG_PN=WAV;DLNA.ORG_OP=01;DLNA.ORG_CI=0;DLNA.ORG_FLAGS=01700000000000000000000000000000" duration="2:50:45.000" size="44" nrAudioChannels="2" sampleFrequency="44100" bitsPerSample="24">http://10.0.0.3:52100/Music/F174131.wav</res>
<res protocolInfo="http-get:*:image/jpeg:DLNA.ORG_PN=JPEG_SM;DLNA.ORG_OP=00;DLNA.ORG_CI=1">http://10.0.0.3:52100/ARrs/174131.jpg</res>
<res protocolInfo="http-get:*:image/jpeg:DLNA.ORG_PN=JPEG_TN;DLNA.ORG_OP=00;DLNA.ORG_CI=1">http://10.0.0.3:52100/ARrt/174131.jpg</res>
</item>
</DIDL-Lite>
</CurrentURIMetaData>
</u:SetAVTransportURI>
</s:Body>
</s:Envelope>
Disk space for the MC temp dir?
Note that when the conversion is done in the library, the temp file is usually where the original sits, not in the MC temp fir.
326 GB free for the library drive.Perhaps.
488 GB free on the drive holding JRiver's conversion cache.
Would JRiver's logging note anything of interest?
Start the logging just before the attempt to get the file.
Stop it immediately afterwards.
Post the results here.
Log from MC 20.0.30 attached (trimmed somewhat to fit within the stated maximum attachment size of 700 KB).
That logfile is about 2000 seconds long and I don't see a reference to a ogg file in it.
Can you turn on the logging just before trying the file request and turn it off just after?
You shouldn't get more than about 30 seconds of logging.
My mousing may not be the fastest, but I think I would have noticed if I spent half an hour before closing the log file! :)Just going by the time stamps to come up with the 2000 seconds.
All of the .wav file references are on behalf of ogg files, though, as those were the only items populating the directory in question. (If the DLNA server is setup to always convert, the renderer is always going to request .wav isn't it? The log does show transcoder activity.)
I'll try again this weekend. Perhaps I had just left logging enabled, resulting in far more being gathered than I intended.
(Edit: fixed typo)
Are you running with default settings for MC in general?
Do you have memory playback enabled? It seems so from the log. I wouldn't expect that to affect the conversion but you could try turning it off if it's on.
I'll try and capture a much shorter log tomorrow.
Bump.Did you try pulling the URL from a browser or pushing to another instance of MC?
I do think this issue is distinct from the SetNext woes with the Yamaha. I uploaded a fairly short log from JRiver in my post on 8 Nov 2014.
Did you try pulling the URL from a browser or pushing to another instance of MC?
Yes, pulling into Chrome directly worked fine.
MP3 and AAC files play fine with the DLNA server converting to PCM 24 or PCML24. It's just Ogg Vorbis files (all of them) that have this hiccup for me with the Yamaha as the renderer. I guess I'll chalk it up as another oddity for the Yamaha. Thank goodness PCM L16 (with SetNext disabled) works and sounds great.
POST /MediaRenderer_AVTransport/control HTTP/1.1
Accept: */*
Content-Type: text/xml; charset="utf-8"
Host: 199.242.131.67:61077
Soapaction: "urn:schemas-upnp-org:service:AVTransport:1#SetAVTransportURI"
Accept-Encoding: gzip
User-Agent: Microsoft-Windows-XP/2002, UPnP/1.1, JRiver Internet Reader/2.0 (compatible; Windows-Media-Player/10)
Content-Length: 2197
Connection: Keep-Alive
Cache-Control: no-cache
<?xml version="1.0" encoding="UTF-8" ?><s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<s:Body>
<u:SetAVTransportURI xmlns:u="urn:schemas-upnp-org:service:AVTransport:1">
<InstanceID>0</InstanceID>
<CurrentURI>http://199.242.131.131:52109/Music/F389213.wav</CurrentURI>
<CurrentURIMetaData><DIDL-Lite xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/" xmlns:dlna="urn:schemas-dlna-org:device-1-0" xmlns:av="urn:schemas-sony-com:av" xmlns:pv="http://www.pv.com/pvns/">
<item id="F389213" parentID="0" restricted="1">
<dc:title>No 01 G477</dc:title>
<upnp:class>object.item.audioItem.musicTrack</upnp:class>
<upnp:playbackCount>2</upnp:playbackCount>
<dc:date/>
<pv:playcount>2</pv:playcount>
<pv:lastPlayedTime>2014-11-07T15:04:47</pv:lastPlayedTime>
<pv:addedTime>1415124367</pv:addedTime>
<pv:modificationTime>1414700041</pv:modificationTime>
<upnp:albumArtURI dlna:profileID="JPEG_SM">http://199.242.131.131:52109/AArs/389213.jpg</upnp:albumArtURI>
<upnp:albumArtURI dlna:profileID="JPEG_TN">http://199.242.131.131:52109/AArt/389213.jpg</upnp:albumArtURI>
<res protocolInfo="http-get:*:audio/wav:DLNA.ORG_PN=WAV;DLNA.ORG_OP=01;DLNA.ORG_CI=0;DLNA.ORG_FLAGS=01700000000000000000000000000000" duration="0:18:08.000" size="287884844" nrAudioChannels="2" sampleFrequency="44100" bitsPerSample="24">http://199.242.131.131:52109/Music/F389213.wav</res><res protocolInfo="http-get:*:image/jpeg:DLNA.ORG_PN=JPEG_SM;DLNA.ORG_OP=00;DLNA.ORG_CI=1">http://199.242.131.131:52109/ARrs/389213.jpg</res>
<res protocolInfo="http-get:*:image/jpeg:DLNA.ORG_PN=JPEG_TN;DLNA.ORG_OP=00;DLNA.ORG_CI=1">http://199.242.131.131:52109/ARrt/389213.jpg</res>
</item>
</DIDL-Lite>
</CurrentURIMetaData>
</u:SetAVTransportURI>
</s:Body>
</s:Envelope>