Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[mattlovell]

Hello,

With JRiver Media Center 20.0.26 (under Windows 7) and a Yamaha RX-A1040 AV receiver, I'm trying to make use of the Audiophile DAC DLNA server.

MP3 files ripped from my CD collection (and .m4a files from iTunes) will play fine.  The .aif files from the HDTracks sampler also play. 

What I'm having an issue with is ogg vorbis files.  The log below seems to show that the .wav files getting constructed by JRiver are extremely short in size.  (The ogg vorbis source for the first file is 470,093 KB in size).  After not playing the first selected file, the receiver then tries the remaining files in that directory:

959  5:45pm  Finished   10.0.0.79   POST:http://10.0.0.3:52101/ContentDirectory/control   3.5KB
960  5:45pm  Finished   10.0.0.79   GET:http://10.0.0.3:52101/Music/F174131.wav  44 bytes
961  5:45pm  Finished   10.0.0.79   GET:http://10.0.0.3:52101/Music/F207353.wav  44 bytes
962  5:45pm  Finished   10.0.0.79   GET:http://10.0.0.3:52101/Music/F34141.wav  44 bytes


Are there any problems with conversion of Ogg Vorbis to PCM/24?  Is there some other setting I should be trying?

I have not modified the Audiophile DAC server settings.  (Well, I *did* try PCM 24-bit w/o Headers.  That resulted in larger file transfers that still didn't play.)

Any insights appreciated.  Thanks.

  Matt

[mattlovell]

Attached is a log captured when repeating the problem.

Here is a portion of the log for one of the GET requests:

6605129: 11084: Sharing Plugins: CHTTPListenerWorker::HandleConnection: Start
6605129: 11084: Sharing Plugins: CHTTPListenerWorker::HandleRequest: TCP: 10.0.0.79: GET: http://10.0.0.3:52101/Music/F174131.wav
6605129: 11084: Sharing Plugins: CMediaFileServer::RespondToFileRequest: Start
6605145: 11084: Sharing Plugins: CMediaFileServer::RespondToFileRequest: Finish (16 ms)
6605145: 11084: Database: CDataHolder::Load: Field: Number Plays; Files: 14957; Pointer bytes: 35348; Data bytes: 16440; Elapsed ms: 1.034
6605145: 11084: Database: CDataHolder::Load: Field: Stack Top; Files: 14957; Pointer bytes: 5260; Data bytes: 16440; Elapsed ms: 0.574
6605145: 11084: Database: CDataHolder::Load: Field: Last Played; Files: 14957; Pointer bytes: 35348; Data bytes: 16440; Elapsed ms: 1.066
6605145: 11084: Database: CDataHolder::Load: Field: Usage Reporting Info; Files: 14957; Pointer bytes: 0; Data bytes: 48; Elapsed ms: 0.551
6605145: 11084: Database: CDataHolder::Load: Field: Store Field: Store Name; Files: 14957; Pointer bytes: 0; Data bytes: 48; Elapsed ms: 0.552
6605160: 10248: General: CMCUICore::SystemPowerManager_UpdateActions: Start
6605160: 10248: General: CMCUICore::SystemPowerManager_UpdateActions: UI Mode: -999; Playing: 0
6605160: 10248: General: CMCUICore::SystemPowerManager_UpdateActions: Finish (result: 0) (0 ms)
6605207: 10696: Playback: CMJPlayerCore::Play: Start
6605207: 10696: Playback: CMJPlayerCore::Play: Created feeder helper for type ogg (native: 1)
6605207: 10696: Playback: CMJWaveFeeder::Play: Start
6605207: 10696: Playback: CMJWaveFeeder::Play: Finish (0 ms)
6605207: 10696: Playback: CMJPlayerCore::Play: Play succeeded
6605207: 10696: Playback: CMJPlayerCore::Play: Result: 1
6605207: 10696: Playback: CMJPlayerCore::Play: Finish (0 ms)
6605207: 10292: Playback: CMJWaveFeeder::Thread: Start
6605207: 10292: Playback: CMJWaveFeeder::Thread: Adding skinning
6605207: 10292: Playback: CMJWaveFeeder::Thread: Opening file
6605207: 10292: Playback: CMJWaveFeeder::Thread: Setting output format
6605207: 10292: Playback: CWaveOutBin::DestroyBin: Start
6605207: 10292: Playback: CWaveOutBin::DestroyBin: Finish (0 ms)
6605207: 10292: Playback: CAutoConfigureAudioOutput::GetOutputFormat: Start
6605207: 10292: Playback: CAutoConfigureAudioOutput::GetOutputFormat: Using input format
6605207: 10292: Playback: CAutoConfigureAudioOutput::GetOutputFormat: Applying output format settings
6605207: 10292: Playback: CAutoConfigureAudioOutput::GetOutputFormat: 44.1kHz 16bit 2ch
6605207: 10292: Playback: CAutoConfigureAudioOutput::GetOutputFormat: Finish (0 ms)
6605207: 10292: Playback: CWaveOutBin::CreateBin: Start
6605207: 10292: Playback: CWaveOutBin::DestroyBin: Start
6605207: 10292: Playback: CWaveOutBin::DestroyBin: Finish (0 ms)
6605207: 10292: Playback: CAutoConfigureAudioOutput::GetOutputFormat: Start
6605207: 10292: Playback: CAutoConfigureAudioOutput::GetOutputFormat: Using input format
6605207: 10292: Playback: CAutoConfigureAudioOutput::GetOutputFormat: Applying output format settings
6605207: 10292: Playback: CAutoConfigureAudioOutput::GetOutputFormat: 44.1kHz 16bit 2ch
6605207: 10292: Playback: CAutoConfigureAudioOutput::GetOutputFormat: Finish (0 ms)
6605207: 10292: Playback: CWaveOutBin::CreateBin: Finish (0 ms)
6605207: 10292: Playback: CMJWaveFeeder::Thread: Preparing to feed data
6605207: 10292: Playback: CMJWaveFeeder::Thread: Memory playback: 0; Maximum play buffer bytes: 1073741824; Grow by bytes: 33554432; System available bytes: 4294967295
6605207: 10292: Playback: CMJWaveFeeder::Thread: Running feeder loop
6605207: 10944: Playback: CWaveOutBinPlayThread::Thread: Start
6606221: 11084: Sharing Plugins: VHTTPMessage::Write: Wrote 44 bytes
6606221: 11084: Sharing Plugins: CHTTPListenerWorker::HandleConnection: Finish (1092 ms)
6606237: 10248: General: CMCUICore::SystemPowerManager_UpdateActions: Start
6606237: 10248: General: CMCUICore::SystemPowerManager_UpdateActions: UI Mode: -999; Playing: 0
6606237: 10248: General: CMCUICore::SystemPowerManager_UpdateActions: Finish (result: 0) (0 ms)

[mattlovell]

MP3 files ripped from my CD collection (and .m4a files from iTunes) will play fine.  The .aif files from the HDTracks sampler also play. 

I've verified that JRiver MC19 and MC20, using the default Audiophile DAC server settings, will stream MP3, M4A, ALAC, AIF, and FLAC files to the Yamaha RX-A1040 successfully (converting all to 24-bit PCM).  The Yamaha also successfully extracts tag information and, when available, album cover art.  The only file type (thus far) that experiences a hiccup is Ogg Vorbis.

Given that the server settings are configured to always convert to PCM, I wouldn't think the Yamaha DAC's support or non-support of Ogg Vorbis should be an issue -- it should never see the original file type anyway.

Any thoughts (or suggestions of modifications to try)?  The majority of my classical music collection is currently in Ogg Vorbis.

Thanks,
  Matt

[bob]

Is there something special about those ogg files?
I tried your test here (pushing to another MC) and it worked fine.

[mattlovell]

Is there something special about those ogg files?

Not to my knowledge (other than having empty tags).

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.

[mattlovell]

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.

I recall a little more detail now...  JRiver was used for the original CD extract and encode.  The files were then merged into a single file using Audacity.

Tags themselves (album title, artist name, track title, etc) are all blank (I never entered any details, as the file's name and location summarize matters nicely).  Other details regarding the file in question:

• Bitrate: 392 kb/s
• Size: 481.4 MB
• Frequency: 44100 Hz
• Duration: 2:50:45

[bob]

You are probably exceeding the maximum file size for a transcoding to wave which is 2gb IIRC.
Does the PCM w/o header play for you on smaller files?

[mattlovell]

You are probably exceeding the maximum file size for a transcoding to wave which is 2gb IIRC.

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.)

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.

Does the PCM w/o header ply for you on smaller files?

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

[mattlovell]

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? 

One other thought came to mind...

Given the ability to have gapless track switching, would it be at all possible to recognize large files and automatically fragment them for streaming playback?

Such fragmentation would somewhat confuse playback, of course (since the "next" track would still end up being the same file, just later on in time), but seems like it may be preferable to either no playback or having to re-encode one's library.  
 

[bob]

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.)

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

All DLNA compliant devices are required to play 16-bit PCM headerless (aka L16).
Only one device I've seen will play 24-bit PCM headerless (aka L24).

IIRC the MP3 high is 320k CBR

I don't know about segmenting the files, that may work, it would of course depend on proper renderer support of SetNextAVTransportURI

[mattlovell]

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) 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.

Any other thoughts?

Thanks,
  Matt

[mattlovell]

No, 24-bit PCM playback even on fairly short ogg files (31 MB, 18min duration) experience the same problem.

PCM L16 (no header) works for both the large and small ogg files.

[bob]

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.

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).

[mattlovell]

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).

Conversion of the small Ogg Vorbis file to 24-bit PCM via this route worked fine.

Conversion of the large file (the opera) also succeeded, producing a file 2,647,396 KB  (2.52 GB) in length.

[mattlovell]

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...

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?

[bob]

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...

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?

Thanks...

[mattlovell]

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?

Channels: 2
Bitrate: 275 kb/s
Frequency: 44.1 kHz
Size: 32,507,660 bytes (31.0 MB)
Duration: 18 min, 8 sec
Encoder: 0 (not that I'm sure what that means)

I wish I could share the file with you, for testing purposes. 

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?

Yes, specified format (PCM L16).  Sample rate is "same as source" and stereo downmix is on.  (Here I just copied what your Audiophile DAC had for settings.)

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?

It only occurs when using PCM (again, I think I have L16 selected); at least, I've never heard it when using high-quality MP3 for streaming.  Once triggered, it seems to occur for every pushed/forced track change.  If left alone (i.e., on the current playlist), track advances happen cleanly.  The brief noise also seems independent of the source file (for the currently-playing or next-selected track), but I'll have to start taking better notes!

I will try disabling SetNext when I return home.

Thanks,
  Matt

[mattlovell]

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!

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)? 

[bob]

My experimentation has been limited (about 10 minutes of switching tracks), but disabling SetNext appears to have resolve the issue!

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)? 

Our use of SetNextAVTransportURI depends on the proper functioning of GetMediaInfo. You might want to let them know that.
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.

[mattlovell]

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.

Here's the device XML for the RX-A1040.  Looks like they do (if seeing service:AVTransport:1 is what I'm looking for).

<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>

[mattlovell]

Service XML for the RX-A1040 includes the following:

<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>

[mattlovell]

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

[bob]

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.

[mattlovell]

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.

The latest Yamaha Aventage receivers claim to accept 24-bit PCM natively.

I'll set up the Audiophile DAC again (set to Always Convert to PCM L24) and get a capture with Wireshark this evening.

[bob]

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.

[mattlovell]

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.

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) is

   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>&lt;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/"&gt;
&lt;item id="F174131" parentID="0" restricted="1"&gt;
&lt;dc:title&gt;La Finta Giardiniera&lt;/dc:title&gt;
&lt;upnp:class&gt;object.item.audioItem.musicTrack&lt;/upnp:class&gt;
&lt;upnp:playbackCount&gt;25&lt;/upnp:playbackCount&gt;
&lt;dc:date/&gt;
&lt;pv:rating&gt;5&lt;/pv:rating&gt;
&lt;pv:playcount&gt;25&lt;/pv:playcount&gt;
&lt;pv:lastPlayedTime&gt;2014-10-21T21:26:13&lt;/pv:lastPlayedTime&gt;
&lt;pv:addedTime&gt;1371954919&lt;/pv:addedTime&gt;
&lt;pv:modificationTime&gt;1372986361&lt;/pv:modificationTime&gt;
&lt;upnp:albumArtURI dlna:profileID="JPEG_SM"&gt;http://10.0.0.3:52100/AArs/174131.jpg&lt;/upnp:albumArtURI&gt;
&lt;upnp:albumArtURI dlna:profileID="JPEG_TN"&gt;http://10.0.0.3:52100/AArt/174131.jpg&lt;/upnp:albumArtURI&gt;
&lt;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"&gt;http://10.0.0.3:52100/Music/F174131.wav&lt;/res&gt;
&lt;res protocolInfo="http-get:*:image/jpeg:DLNA.ORG_PN=JPEG_SM;DLNA.ORG_OP=00;DLNA.ORG_CI=1"&gt;http://10.0.0.3:52100/ARrs/174131.jpg&lt;/res&gt;
&lt;res protocolInfo="http-get:*:image/jpeg:DLNA.ORG_PN=JPEG_TN;DLNA.ORG_OP=00;DLNA.ORG_CI=1"&gt;http://10.0.0.3:52100/ARrt/174131.jpg&lt;/res&gt;
&lt;/item&gt;
&lt;/DIDL-Lite&gt;
</CurrentURIMetaData>
</u:SetAVTransportURI>
</s:Body>
</s:Envelope>

[bob]

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) is

   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>&lt;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/"&gt;
&lt;item id="F174131" parentID="0" restricted="1"&gt;
&lt;dc:title&gt;La Finta Giardiniera&lt;/dc:title&gt;
&lt;upnp:class&gt;object.item.audioItem.musicTrack&lt;/upnp:class&gt;
&lt;upnp:playbackCount&gt;25&lt;/upnp:playbackCount&gt;
&lt;dc:date/&gt;
&lt;pv:rating&gt;5&lt;/pv:rating&gt;
&lt;pv:playcount&gt;25&lt;/pv:playcount&gt;
&lt;pv:lastPlayedTime&gt;2014-10-21T21:26:13&lt;/pv:lastPlayedTime&gt;
&lt;pv:addedTime&gt;1371954919&lt;/pv:addedTime&gt;
&lt;pv:modificationTime&gt;1372986361&lt;/pv:modificationTime&gt;
&lt;upnp:albumArtURI dlna:profileID="JPEG_SM"&gt;http://10.0.0.3:52100/AArs/174131.jpg&lt;/upnp:albumArtURI&gt;
&lt;upnp:albumArtURI dlna:profileID="JPEG_TN"&gt;http://10.0.0.3:52100/AArt/174131.jpg&lt;/upnp:albumArtURI&gt;
&lt;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"&gt;http://10.0.0.3:52100/Music/F174131.wav&lt;/res&gt;
&lt;res protocolInfo="http-get:*:image/jpeg:DLNA.ORG_PN=JPEG_SM;DLNA.ORG_OP=00;DLNA.ORG_CI=1"&gt;http://10.0.0.3:52100/ARrs/174131.jpg&lt;/res&gt;
&lt;res protocolInfo="http-get:*:image/jpeg:DLNA.ORG_PN=JPEG_TN;DLNA.ORG_OP=00;DLNA.ORG_CI=1"&gt;http://10.0.0.3:52100/ARrt/174131.jpg&lt;/res&gt;
&lt;/item&gt;
&lt;/DIDL-Lite&gt;
</CurrentURIMetaData>
</u:SetAVTransportURI>
</s:Body>
</s:Envelope>

Hard to square that with my results which were that it played fine.
The size is 44 bytes which is the wav header. For some reason the conversion is failing on your particular computer.
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.

[mattlovell]

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.
488 GB free on the drive holding JRiver's conversion cache.

Would JRiver's logging note anything of interest?

[bob]

326 GB free for the library drive.
488 GB free on the drive holding JRiver's conversion cache.

Would JRiver's logging note anything of interest?

Perhaps.
Start the logging just before the attempt to get the file.
Stop it immediately afterwards.
Post the results here.

[mattlovell]

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).

Play attempts to start with http://10.0.0.3:52101/Music/F10858.wav, and then attempts to move to F10859.wav, then seemingly goes back to try F10858.wav again (twice), then F10859.wav, F10860.wav, F10861.wav, and so on.

[mattlovell]

Log from MC 20.0.30 attached (trimmed somewhat to fit within the stated maximum attachment size of 700 KB).

Upgraded to MC 20.0.33; no change to report on this issue.

[bob]

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.

[mattlovell]

That logfile is about 2000 seconds long and I don't see a reference to a ogg file in it.

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!

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.)

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.

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)

[bob]

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!

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)

Just going by the time stamps to come up with the 2000 seconds.
Anyway, I see the wav file. Nothing unusual as far as I can see except that it's logged as 16 bits and it's clearly 24 (duplicated here so the logging must not be taking that into account).
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.

[mattlovell]

Are you running with default settings for MC in general?

Yes, I don't think I've strayed very far from defaults.

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.

Nope, memory playback is not enabled, at least not generally.  It wouldn't get enabled for transcoding to 24-bit PCM, would it? 

(In the other thread we have going, regarding initial static/pops/stuttering upon a pushed track change, I was about to ask about a possible race condition between transcoding data being available and the AV Transport "play" getting issued to the renderer.  Don't know if that's a useful train of thought to pursue or not.)

I'll try and capture a much shorter log tomorrow.

[mattlovell]

I'll try and capture a much shorter log tomorrow.

New log, attempting to play just one Ogg file via 24-bit PCM (the Audiophile DAC), attached.

[mattlovell]

I notice that the log contains the line

0656233: 3544: Playback: CMJWaveFeeder::Thread: Memory playback: 0; Maximum play buffer bytes: 1073741824; Grow by bytes: 33554432; System available bytes: 4294967295

but, as I mentioned already, I do not have Memory Playback enabled (at least not under Tools -> Options -> Audio / Settings)

[mattlovell]

I should also likely note that setting up conversion to PCM 16 (with Headers) also doesn't work.  So, PCM 16 and PCM 24 aren't happy, only PCM L16 will stream Ogg Vorbis for me (out of the bit-accurate choices).

Conversion to MP3 does work, but tickles a separate problem (initial static/popping/stutter).

[mattlovell]

Bump.

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.

[bob]

Bump.

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?
I am unable to duplicate this behavior.
Several of the devices I have which can play 16 and 24 bit PCM, with and without headers, work perfectly with your test file.

[mattlovell]

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.

[bob]

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.

I did a detailed validation on the wave file produced by my push of a 24 bit wave from your sample file to the renderer and it was fine.
If you want to pursue this further, when you push that file as 24 bit PCM (not headerless) format to the renderer you could check the SetAVTransportURI.

This is what I get:

Code: [Select]

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>&lt;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/"&gt;
&lt;item id="F389213" parentID="0" restricted="1"&gt;
&lt;dc:title&gt;No 01 G477&lt;/dc:title&gt;
&lt;upnp:class&gt;object.item.audioItem.musicTrack&lt;/upnp:class&gt;
&lt;upnp:playbackCount&gt;2&lt;/upnp:playbackCount&gt;
&lt;dc:date/&gt;
&lt;pv:playcount&gt;2&lt;/pv:playcount&gt;
&lt;pv:lastPlayedTime&gt;2014-11-07T15:04:47&lt;/pv:lastPlayedTime&gt;
&lt;pv:addedTime&gt;1415124367&lt;/pv:addedTime&gt;
&lt;pv:modificationTime&gt;1414700041&lt;/pv:modificationTime&gt;
&lt;upnp:albumArtURI dlna:profileID="JPEG_SM"&gt;http://199.242.131.131:52109/AArs/389213.jpg&lt;/upnp:albumArtURI&gt;
&lt;upnp:albumArtURI dlna:profileID="JPEG_TN"&gt;http://199.242.131.131:52109/AArt/389213.jpg&lt;/upnp:albumArtURI&gt;
<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>

Code: [Select]

<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>