Topic: Intermittent streaming via DLNA from my iMac (Read 3765 times)

rippolito · « **on:** August 12, 2020, 11:08:36 am »

Bob or Jim or anybody,

Streaming through DLNA from my iMac to a SotM SMS-200 DLNA renderer seems hit or miss. Sometimes, I can stream from a Cloudplay playlist (click on the 'play' icon when displaying a playlist), and if I download the same playlist and attempt to play it on my mac, it plays. But oftentimes, when I attempt the same process on other playlists, it often fails. I get an Information box in the center of the screen stating 'There was a problem controlling the selected DLNA device. Double-check your device, server, and network settings'. After hitting 'OK', a playback problem box appears, stating 'Something went wrong with playback'. Does that make sense to you why some work, and others do not?

Another oddity that I discovered is that when I download those playlists that played successfully from Cloudplay, they play fine when I open them on my iMac. If I had previously downloaded them (most I downloaded six or eight months ago), the originally downloaded one never plays. As a matter of fact, NONE of the previously-downloaded playlists now play via the DLNA path to my DAC.

When I reattach a USB cable from my iMac to the DAC, everything plays successfully as it did when originally downloaded.

I can't get YouTube to stream successfully, or Radio Paradise, but one of the others on this thread said they were successful with Radio Paradise. If one works, why don't they all work?

Can you please shed some light on my dilemma, and point me in a direction?

Thank you, in advance, for any help you can give me...
Ron

rippolito · « **Reply #1 on:** August 12, 2020, 03:19:35 pm »

Has anyone else seen this condition? Can someone go to Cloudplay and play multiple playlists from the cloud, and confirm whether all play, or sometimes they do not?

Thank you...
Ron

RoderickGI · « **Reply #2 on:** August 18, 2020, 09:06:43 pm »

Mostly answered over here: https://yabb.jriver.com/interact/index.php/topic,126511.msg877282.html#msg877282

Cloudplay has changed a lot in eight months. Redownload the Playlists that no longer work, and delete the old ones. Playing via USB is completely different to playing via DLNA, so there could be settings differences you have between the two audio paths.

You would have to share which Cloudplay Playlists always work when you play to your SotM SMS-200 DLNA Renderer, and which always do not, for any comment on that issue. Do note though that some files on Cloudplay are APE rather than FLAC, so if that is the common attribute, it could be your DLNA settings aren't handling APE files correctly.

Radio Paradise should stream successfully via DLNA to your SotM SMS-200 DLNA Renderer. It is a stream of FLAC files, and is handled correctly by MC. Check settings.

YouTube will not play via DLNA to your SotM SMS-200 DLNA Renderer. I assume you are using the WDM Driver to send YouTube audio to MC, and are then trying to play that to your Renderer. Audio sourced through the WDM Driver cannot be sent to a DLNA Renderer. There have been several discussion as to why this is, but basically it is not currently technically possible. That may change in future. YouTube should play via the WDM Driver and a USB connection to your DAC.

RoderickGI · « **Reply #3 on:** August 18, 2020, 09:57:00 pm »

This seemed the better thread to continue this conversation from over here: https://yabb.jriver.com/interact/index.php/topic,126511.msg877282.html#msg877282

The Cloudplay Playlist (Algol's Grammy Albums) that I mentioned in that other thread played fine up to the eighth track, which it then had lots of trouble with. JRiver for Android played five seconds of the track, then stopped for fifty-five (variable) seconds, then played five more seconds, and kept repeating that process. It is currently up to 1:03 minutes on the phone, out of 4:05 minutes. So it seems that something is trying to restart playback every minute at the moment. The song is progressing though, slowly, five seconds at a time, every minute.

Having a DLNA Renderer play five seconds of a track, then stop or have playback issues, is typical of a DLNA Controller (MC in this case) having trouble controlling or receiving status information from the DLNA Renderer (JRiver for Android in this case) it is playing to. Typically those issues are fixed by changing the "DLNA Controller Options" in MC. But I would have expected JRiver for Android to work if any Renderer was going to, but that may be a misplaced expectation, as JRiver for Android is still a work in progress.

I think the issue is either Android, or JRiver for Android, and I'm looking squarely at JRiver for Android. MC isn't sending any additional data to the phone, so the phone has the whole track, and just isn't playing it. However, JRiver for Android isn't showing the full duration of the track (4:05), so it could be that MC failed to send that data, which it should have done, and this is an issue with MC's DLNA implementation. I'll have to restart a test to see if for the previous tracks JRiver for Android had the durations. I want to see if the current track complete and then what happens to the next track.

Anyway, your circumstances may be completely different, because you are using a different Renderer.

So I guess share some more information about which Cloudplay Playlists won't play, what happens when playback stops, if your Renderer just completely stops or plays a little bit more if you wait long enough, if it plays a few tracks and then stops is it always after the same number of tracks, and so on.

EDIT:
The eighth track never fully finished. The ninth track started playing wi the same issue, five seconds at a time. JRiver for Android never updated the Cover Art or track information to the ninth track.
This is disappointing.
Stopping playback and restarting playback worked, with the ninth track playing correctly. JRiver for Android still didn't display the duration.

JimH · « **Reply #4 on:** August 18, 2020, 10:31:13 pm »

In Cloudplay settings, try setting the bandwidth limit to 1000.

rippolito · « **Reply #5 on:** August 19, 2020, 01:35:22 pm »

RoderickGl,

Here is an example of a playlist that will not play on my SMS-200, whether I try to play it from the Cloud or after I download it to my iMac

- Playlist author - jaxtherogue
- Playlist title - Ring Out Solstice Bells
- 1st song in the playlist (that never plays) - Jingle Bells Pt.1

When I disconnect from the SMS-200 and connect directly to my Qutest DAC via USB, it plays without issue. However, it never tells me what format this file is (flac, aif, wav, etc).
Ron

JimH · « **Reply #6 on:** August 19, 2020, 01:42:30 pm »

I can play that file locally. It's a FLAC file.

rippolito · « **Reply #7 on:** August 19, 2020, 01:54:54 pm »

Jim,

Thanks for the quick response.

When I view the contents of a Cloudplay playlist, is that the order that the songs will play?
Ron

RoderickGI · « **Reply #8 on:** August 19, 2020, 05:47:26 pm »

Cloudplay Playlists are just like other Playlists. They are played in the order displayed. Note though that there are settings in "Options > Cloudplay > Set file that can be included for playback" which will filter out tracks that don't match the rules.

The file you listed always plays. But MC is sending FLAC to my DLNA devices, and not applying the Output Format or DSP I have set.

I set up MC playing from once PC to another using DLNA, rather than Client/Server, and that track played fine. But it was sent as a FLAC file, rather than being converted to "PCM L16 No header" as per my settings. However I had "Audio > Mode" set to "Specified output format only when necessary" so MC would just have been determining that the target MC installation could play FLAC, so that is what it sent. However, when I changed the "Audio > Mode" set to "Specified output format" it still sent FLAC, which it should not have done, I would have thought. I also tried adding DSP to force the source installation to convert the format, but it didn't. It also did show it was using the Audio Path in the source installation.

So, all of the above was fruitless. I assume that the MC source knew it was playing to a MC target, so it didn't use the DLNA settings. Grrr.

So back to BubbleUPnP to test... Well that didn't work either. MC just sent FLAC files to Bubble regardless of settings.

I've had enough of testing DLNA for now. It seems broken, broken, broken the more I try it. I'll go back and review DSP over DLNA later and see if that is working and I am just doing something wrong. It could just be my network, which still requires a kick in the pants for MC to even to see DLNA Renderers.

rippolito · « **Reply #9 on:** August 21, 2020, 01:50:26 pm »

Bob or Jim or RoderickGI,

Is there a log that JRiver MC saves that would tell us (you) why I am getting the error message that the requested playlist won't stream? If so, what is the log's name, and how can I send it to you?
Ron

rippolito · « **Reply #10 on:** August 22, 2020, 04:52:37 pm »

OK, here is a big step forward, at least from the diagnostic standpoint that I can pretty much guaranty when a stream will, or will not, play on my sms-200...

- if a song has a bitrate listed, the stream works successfully on the sms-200
- on the playlist I sent earlier this week (Ring Out Solstice Bells), the first song has no bitrate, so I get the error. When I select any other of the songs, which all have bitrates listed, they all play.
- the same holds true for songs on my local hard drive. If there is no bitrate, playing the song fails. If there is a bitrate, playing the song is successful
- if I have a playlist for an internet radio station, the same pattern holds true

Does this make sense to anyone who is smarter than me?
Ron

JimH · « **Reply #11 on:** August 22, 2020, 05:17:43 pm »

That file had a bitrate when I played it. It was an ordinary FLAC file.

Did you download them recently or was it some time ago? Try playing from the server without downloading (by using the small play button at the right end of the listing.

rippolito · « **Reply #12 on:** August 22, 2020, 05:27:54 pm »

Jim,

The same rule applies when I play it from your server: if the first song to play has a bitrate, it plays (I know that because when I download the playlist and look at the first song). If it doesn't play from your server (I get the error message), when I download that playlist, the first song never has a bitrate. If I select other songs in that playlist that have a bitrate, they play.
Ron

RoderickGI · « **Reply #13 on:** August 22, 2020, 08:43:58 pm »

Logging in MC is described here: https://wiki.jriver.com/index.php/Logging

You should be able to look in the logs created and find records where JRiver Radio (Cloudplay) tacks are played back to your DLNA Renderer. Just search for "RadioJRiver" in the log. Notepad++ is a good tool to view and search logs, but any text editor will work. Just make sure to clear the logs before you start a test, so the files are small and it is easy to find what was done in your tests. Have a look yourself before posting a log here. Basically, JRiver won't look at a log unless lots of people have the same problem, or they can reproduce the problem.

All the tracks in the Cloudplay Playlist you mentioned;

Quote from: rippolito on August 19, 2020, 01:35:22 pm

- Playlist author - jaxtherogue
- Playlist title - Ring Out Solstice Bells
- 1st song in the playlist (that never plays) - Jingle Bells Pt.1

have bitrate values. When you play a Cloudplay Playlist all the files should show in Playing Now for your Renderer. Are you saying that if you display the Bitrate column in Playing Now, the value is empty? Because for me, all the tracks have values in that field. Check for values in Playing Now, rather than by downloading the Playlist. Although when I download the above Playlist all tracks have Bitrate values.

I played the Playlist again and checked the log, and the bitrate is also included in the playback command. So I have no idea why you aren't seeing a bitrate for the first file. I can see my DLNA Renderer is selected as the playback device as well, by searching the log for the Renderer name. I don't know enough about MC internals to see more than that, but playback works.

Note however, that the track change time can be quite long, and a few times playback paused for a minute or so before resuming. I couldn't see any reason for that quickly, so I assume MC was waiting to download more of the file from the Amazon AWS server. The first significant pause happened at track 5 in that Playlist for me, and now I am up to track 17 with no further pauses other than track changes.

As noted elsewhere though, MC won't do any DSP on these Cloudplay tracks, and you can't force it to do that. Your Renderer can do volume leveling and so on if it supports it and the tag values exist, but that is all you get.

For clarity, I'm using a licenced version of BubbleUPnP on the phone as a DLNA Renderer now, so no restrictions on playback, and that has made testing easier and playback more reliable.

Jim, one thing that I did notice while testing this that was very, very unusual was that when track change was happening, typing in this post was severely slowed, to the point that words I had typed didn't appear for a second or so after I typed them. This would relate back to the cause of MC "lockups", the "expanding screen" and "whiteout of screen" issues, I would think. There was no significant load on the PC at all, for CPU, GPU, Memory, or Network. MC is obviously using or holding some resources exclusively at some core level of Windows. I have seen other applications do that, very rarely. My Antivirus wan't showing any load either, so I doubt that was it.

RoderickGI · « **Reply #14 on:** August 22, 2020, 08:45:56 pm »

BTW, when you check for Bitrate against tracks in Playing Now, also check if the Duration field has a value in it.

Without a Duration value, MC won't play the track to a DLNA Renderer.

rippolito · « **Reply #15 on:** August 22, 2020, 08:56:39 pm »

Enclosed please find the playlist with the first song having no bitrate. When I hover the mouse over the song, it lists no file type, no bitrate, and no sample rate. All the other files in the playlist have those three items.

Since the files won't play to the sms-200, I never get 'playing now' at the top of the window to display anything. All the other files in the playlist show bitrate, duration.
Ron

RoderickGI · « **Reply #16 on:** August 22, 2020, 09:59:55 pm »

I just downloaded that Playlist again and it had no Bitrate values at all for any track this time.

I played it to the local Player Zone, and in Playing Now none of the tracks had Bitrate values either.

In both cases they had Duration values, and the tracks played on the Player Zone just fine.

I noted that the URL for the tracks in your image is different to the URL in my Playlist and Playing Now. I would guess that is because I am using a mirrored Amazon AWS server in Australia, while you are using one elsewhere. Or it could be part of the obfuscation used for copyright protection. Regardless, that difference may be a contributing factor here.

I am currently getting a huge amount of buffering just trying to play that first track. That could also be an issue for the problem you are seeing.

I just successfully played that Cloudplay playlist to my DLNA Renderer again, with no buffering issues, and this time none of the tracks have Bitrate values there either.

I don't know what all that means, but it doesn't seem right. MC should be seeing the Bitrate values every time, as it would be reading them from file tags, I believe.

BTW, even if the first file won't play, when you try to play directly from Cloudplay to your DLNA Renderer using MC, Playing Now should get populated with the track list. You will need to select your DLNA Renderer under Playing Now to see them though, as per the attached image, where I have selected "BubbleUPnP (G8141)".

If Playing Now isn't being populated you have some other problem, which would be the reason that tracks don't play.

rippolito · « **Reply #17 on:** August 23, 2020, 05:25:04 am »

I captured a log file when I attempted to play the playlist, and it failed on the first track. I also captured a log file when it successfully played the second track.

How can I best get the two log files to you?
Ron

rippolito · « **Reply #18 on:** August 23, 2020, 02:12:33 pm »

How about this? I believe I've found the log statement that initiates the request to play the song.

The first statement is from attempting to play the song that has no bitrate, no file type, and no sample rate. This led to the error condition

0023594: 140735680725888: Playback: CPlayerZone::Play: Playing: <XMLFN version="1.0"><Item Name="Filename">https://s3.amazonaws.com/content.jriver.com/users/124/73744a59336a39786b31306e5731784a7730333737673d3d.flac</Item><Item Name="PlaylistIndex">0</Item><Item Name="AlbumSequentialWithLastTrack">0</Item><Item Name="SampleRate"></Item><Item Name="VolumeReset">1</Item><Item Name="Channels"></Item><Item Name="ErrorFreeMode">0</Item><Item Name="VolumePeakLevels"></Item><Item Name="MediaType">Audio</Item><Item Name="DatabaseKey">6911836</Item><Item Name="VolumeTrackMaxSafeGain">-1</Item><Item Name="Bitrate"></Item><Item Name="Bookmark"></Item><Item Name="BitDepth"></Item><Item Name="LengthInPCMBlocks">-1</Item><Item Name="RadioJRiver">1</Item><Item Name="VolumeLeveling">-10</Item><Item Name="DSP"></Item><Item Name="FileType"></Item><Item Name="UserInterfaceModeChangeEventHandle">0000000000000000</Item></XMLFN>

Then, the error statement denoting that the request to the sms-200 had failed
0023846: 140735680725888: General: CDLNADeviceServiceCaller::CallServiceFunction: DLNA function call failed or timeout! url = http://192.168.10.130:49152/uuid-49fa9abc-6b70-7daf-7390-08beac0eeb6d/ctl-urn-schemas-upnp-org-service-AVTransport-1 function = SetAVTransportURI execution time = 52 ms of 6000 ms.]
- The second statement is from the attempt to play the second song in the playlist. This successful attempt contains the bitrate, file type, and sample rate
  
  0013005: 140735680725888: Playback: CPlayerZone::Play: Playing: <XMLFN version="1.0"><Item Name="Filename">https://s3.amazonaws.com/content.jriver.com/users/124/315448504d757832675247706a37704966442b6a54673d3d.flac</Item><Item Name="PlaylistIndex">1</Item><Item Name="AlbumSequentialWithLastTrack">0</Item><Item Name="SampleRate">44100</Item><Item Name="VolumeReset">1</Item><Item Name="Channels">2</Item><Item Name="ErrorFreeMode">0</Item><Item Name="VolumePeakLevels">+0.2 dBTP; +0.2 Left; +0.1 Right</Item><Item Name="MediaType">Audio</Item><Item Name="DatabaseKey">6911669</Item><Item Name="VolumeTrackMaxSafeGain">-1.2</Item><Item Name="Bitrate">898</Item><Item Name="Bookmark"></Item><Item Name="BitDepth">16</Item><Item Name="LengthInPCMBlocks"></Item><Item Name="RadioJRiver">1</Item><Item Name="VolumeLeveling">-9</Item><Item Name="DSP"></Item><Item Name="FileType">flac</Item><Item Name="UserInterfaceModeChangeEventHandle">0000000000000000</Item></XMLFN>li]
Ron

RoderickGI · « **Reply #19 on:** August 23, 2020, 05:22:09 pm »

Normally JRiver only asks for logs when they think there is a common problem or a bug. So probably no-one from JRiver will look at them, but you can attach the original zip file log to a post here if you wish. Don't just attach the txt files from within them though. The whole zip file. I could have a bit of a look, but I can't make much sense of DLNA problems in logs. If the zip files are too big, you can upload them to a site such as Dropbox or Google Drive, and share a link to them.

As I said above, I started seeing tracks with no Bitrate, and playback still worked. Maybe this is something very particular to your Renderer. Does playback of local files to your Rendereer ever fail with the same or similar messages?

Have you tried completely powering down your Renderer (pull the plug), waiting 30 seconds, and then restarting it when this happens? You said it is, or was, an intermittent problem in your original post. Maybe it is just the Renderer getting into trouble and needing a restart.

rippolito · « **Reply #20 on:** August 23, 2020, 06:22:21 pm »

Roderick,

I have a local file that has no bitrate, and when I submit it to the sms-200, it fails in the same manner.
Ron

rippolito · « **Reply #21 on:** August 23, 2020, 06:32:29 pm »

Roderick,

When I started this thread with 'intermittent streaming' in the subject, I meant that sometimes streaming works, and other times it does not.
Ron

RoderickGI · « **Reply #22 on:** August 23, 2020, 09:35:54 pm »

Quote from: rippolito on August 23, 2020, 06:22:21 pm

I have a local file that has no bitrate, and when I submit it to the sms-200, it fails in the same manner.

If that is always the case, I think you should focus on fixing that first, rather than continuing with testing Cloudplay.

I understood that sometimes streaming to your SotM SMS-200 DLNA Renderer worked, and sometimes it didn't, from your first post. As above, if it is always because there is no Bitrate value in the file tag, focus on that for local files.

While the missing Bitrate data is concerning, particularly when you see this for Cloudplay tracks that do have Bitrates (mostly, or sometimes - the data is back for me today), this is starting to sound like it is an issue with your SotM SMS-200 DLNA Renderer not being able to handle such files. Although I just checked, and of 28,000 audio files I have, only one has no Bitrate, only a few have no Sample Rate, and all of those are obscure mid files. They all have Duration values, and play locally, but the Seek Bar doesn't work. They also all play to my BubbleUPnP DLNA Renderer.

The other thing I've found is that MC doesn't seem to play from Cloudplay on a MC Client to a MC Server and hence to my BubbleUPnP DLNA Renderer, sometimes. That is a bit of a convoluted path, but it should work every time. So you whole Cloudplay issue may be unrelated to local issues, and just some problem with Cloudplay itself. Just another reason to focus on playing local files first.

If you were on a Windows system I would get you to run AndrewFG's Digital Media Renderer Analyser, but as you are on an iMac that isn't possible. Maybe there are OSX tools that can test the capability of DLNA Renderers?

What format is the local file that won't play? Sample Rate? Duration?
Do you only have one local file without Bitrate, that won't play?
Can you share a copy of the file through Dropbox, Google Play, OneDrive or similar? (Yes, as others have pointed out, copyright material. But for diagnostic purposes that should be okay. Maybe PM a link to the file, rather than post it on the forum.)

Did you try restarting the Renderer?

rippolito · « **Reply #23 on:** August 24, 2020, 09:20:37 pm »

I got a Windows laptop and can run the Whitebear DLNA tester. What information would be of value to you and me?
Ron

RoderickGI · « **Reply #24 on:** August 24, 2020, 11:20:50 pm »

The report it produces shows what DLNA functions it supports, and which media formats it supports, both of which can help resolve issues.

Beyond that, in terms of deeper interpretation of the report, we would have to get Andrew to comment.

Just post the full report. It isn't usually too big.

AndrewFG · « **Reply #25 on:** August 25, 2020, 06:20:35 am »

I’m not entirely sure where this discussion of bitrate and duration is coming from, or going to ...

... however, when the MC server pushes a track to a renderer, it always sends a ContentLength header; this is normally simply the size of the file on disk; however if the track is not on disk, it may be that MC is supplying a calculated ContentLength instead; this would be Channels x Sample Rate x Bit Depth x Duration / 8, so if any of those data were missing, then ContentLength would fail..

{ IMHO MC could easily solve such a lack of ContentLength another way by sending the file “Chunked”. This is the approach used by other companies e.g. Bubble; but for whatever reason, JRiver chooses not to do it that way. }

AndrewFG · « **Reply #26 on:** August 25, 2020, 06:41:50 am »

Quote

The first statement is from attempting to play the song that has no bitrate, no file type, and no sample rate. This led to the error condition

At least to me, it is obvious that such a file would not play. It is obviously a bad file. So where is it? What is it? And can you put it on a drop box or something, so we can look at it?

rippolito · « **Reply #27 on:** August 25, 2020, 07:51:03 am »

Andrew,

I started this thread because I was getting DLNA errors when playing from Cloudplay playlists to my SotM sms-200 renderer. After a lot of trial and error debugging, I noticed that whenever a playlist failed, the song it failed on had not bitrate (any usually, no sample rate.)

If you go up to the sixth post in this thread, I gave the info on a Cloudplay playlist that always fails on my renderer. if you go down a bit, you'll see a screen snap that shows there is no bitrate in the first song. If I start at the second song, it plays without any failures. I also have a mp3 on my hard drive that has no bitrate, and it fails when I submit that file to the renderer. However, if I play that song on my local 'player' (internal speakers, or via USB to my DAC), it plays without incident. It is only when I submit it to my DLNA renderer that it always fails.

It turns out that there are many, many Cloudplay playlists that contain no bitrate for some, or all, of the songs, so those are a problem for my system. So, given all that, I would be very grateful if someone who knows more than me can give me a workaround that would enable me to utilize Cloudplay to my renderer.
Ron

AndrewFG · « **Reply #28 on:** August 25, 2020, 11:22:40 am »

^
I have never used Cloudplay, so have no experience in debugging it. But I will set it up and do some tests for you in the next couple of days. Can you please tell me the exact link of your track that fails?

rippolito · « **Reply #29 on:** August 25, 2020, 12:27:09 pm »

Andrew and Jim,

I tried to get the exact link to the Cloudplay playlist, and I couldn't figure out how to get it, so I exported the playlist from Media Center. I've attached the first two fields from the playlistit below.

Andrew, if you look at the first song, there are several fields missing, among them bitrate, sample rate, and duration. Per your earlier post, without those fields, the song won't play on the renderer, and it doesn't.

If you look at the second song, those fields are present, and the song plays correctly.

Jim, is there someone in your team could take a look at why some Cloudplay playlists are posted with an incomplete field list?

Thank you...
Ron

rippolito · « **Reply #30 on:** August 25, 2020, 12:28:42 pm »

Sorry about the error - the duration is present in the first song...

RoderickGI · « **Reply #31 on:** August 25, 2020, 05:03:01 pm »

Just to add to the mystery, when I use File > Open URL in MC and try to open the first URL in your text file, the track plays fine for me, both locally to the MC installation (Player Zone), and to my BubbleUPnP Renderer. I will note here however that the URL MC actually plays is a different one, which I assume is because Amazon AWS looks up the local version on local servers in Australia.

When I use that method to play, the file shows up in Playing Now for the Renderer, and it shows it has a [Duration] value, but no [Bitrate], [Sample Rate], [Bit Depth] or even [File Type] values.

A missing [File Type] could be more relevant to a Renderer, as it wouldn't know how to play the file.

RoderickGI · « **Reply #32 on:** August 25, 2020, 05:06:12 pm »

I still think it could be a Renderer specific issue. Posting a report from DMRA wouldn't hurt.

AndrewFG · « **Reply #33 on:** August 26, 2020, 12:26:03 pm »

Ok. I have been doing some testing myself. I couldn't find anything obvious relating to durations or bitrates etc. But here's a thing..
The (HTTP) URL of the first track in your playlist is as follows..

Code: [Select]

http://RadioJRiver:P8zkR/kBFpj/RIVI7RXZ2VnUCQNEoXNcOeZBChf1xtxP5n1+1OcuaZz1Yy3ZBy8wqEmNYpvn0B6Ru2YvQEaTAcyATxO6Eng1vMTZFzEinvTqRpAtR+9aGuKfeCjiVaXHpHFPJhh7Dr1ONsU03j34gu9mI9B1MpfKmdzUmSF9qeIfPmPL6WNXJvTN4c5mm6vuZW1nyiDV212tsqISVxmEpppZW6uwCYSWPHYgkmN3iH6ajeRIkMPtvpB/c8nHVyM2cH34B6iBeLgdYKZTiGklB4zDe964tEdWzcw9HL4zRV/8tQT1TjcT9i/K11yLtEXj3iVSDDq0FdMRvX6NEjFoueUFX5pPYzPWpCUe2s7KcdB3d7SzJT+CrMl3rxy1vcdI8k8MlZtKjSjEs5ITgU/wTLtCrxikQvoE6RW+z8BiKkw6FaRoZlpXqEsXPOGsQNWEOz8fhOziX9ucHQDo1FoTeISY7VDFQe5GFXj3pbdpacBTXDg3W6lYhVkGs+lGdeY0ghsUZtnwMXRYNcuIRXUXewdFRhsTsHnXf6DgnTkB+02qPo2YTtLiZa7yUIvid4Py7SgHUyEiaYM9t5Kahr5Npw==

In MC when I select my Oppo Renderer, and File | Open | Url .. the above URL gets translated to the following (HTTPS) URL..

Code: [Select]

https://s3.amazonaws.com/content.jriver.com/users/124/73744a59336a39786b31306e5731784a7730333737673d3d.flac
Now my Oppo fails to play the above (HTTPS) URL. However, when I select File | Open | Url .. and enter the exact same URL but on the HTTP protocol instead of the HTTPS protocol, then the Oppo plays the track just fine.

Code: [Select]

http://s3.amazonaws.com/content.jriver.com/users/124/73744a59336a39786b31306e5731784a7730333737673d3d.flac
So IMHO the problem with playing these remote URLs may be unrelated to durations or bitrates etc. But rather it may be to do with the fact that Amazon translates the playlist HTTP URL to an HTTPS URL for the actual download, and some UPnP Renderers may not (fully) support the HTTPS protocol. You can imagine that PC based Renderers (such as MC itself, or Bubble) will have super good support for HTTPS, whereas consumer electronics Renderers (such as my Oppo, or the OP's renderer) will not be able to support HTTPS.

{ PS I am not 100% sure, but if I recall it correctly (without looking it up), the UPnP / DLNA specification only mandates support for the HTTP protocol. So in other words HTTPS support is "optional".. }

{ PPS you can see the irony in that MC pushes the track meta data (DIDL) with protocolInfo="http-get" and a URL starting with "HTTPS" .. }

Code: [Select]

<res protocolInfo="http-get:*:audio/x-flac:DLNA.ORG_PN=FLAC;DLNA.ORG_OP=00;DLNA.ORG_CI=0;DLNA.ORG_FLAGS=0F700000000000000000000000000000" size="-1" nrAudioChannels="2" sampleFrequency="44100" bitsPerSample="16">
	https://s3.amazonaws.com/content.jriver.com/users/124/73744a59336a39786b31306e5731784a7730333737673d3d.flac
</res>

rippolito · « **Reply #34 on:** August 26, 2020, 12:37:49 pm »

Andrew,

That is very interesting.

My sms-200 can handle all the subsequent songs in that playlist. Would you be able to look at the second song in the playlist and determine whether the url gets converted to https, as did the first?

Thanks,
Ron

AndrewFG · « **Reply #35 on:** August 26, 2020, 06:29:31 pm »

Your own log shows an HTTPS URL in both cases. So evidently the issue that you see, is not the same as the one that I see. Therefore, I am unfortunately not able to help you further..

Code: [Select]

https://yabb.jriver.com/interact/index.php/topic,126506.msg877713.html#msg877713

RoderickGI · « **Reply #36 on:** August 26, 2020, 06:57:52 pm »

In my log files all the URLs use HTTPS.

The only place I see HTTP URLs is in a downloaded Cloudplay Playlist which I exported, and in the MC [Filename] field in Playing Now and the Playlist inside MC. I guess the latter of those is the source of playback, but as the logs show only HTTPS it might be MC that is converting the HTTP address to HTTPS.

But I think you are on to something there Andrew... EDIT: Or maybe not.

Why would only some files not play though? Maybe it takes a while for the Oppo to switch to handling HTTPS?

Rippolito, what happens if you redownload the "Ring Out Solstice Bells" Cloudplay Playlist and move the first track down to, say, the third track?
Do the first and second tracks play correctly?
Does the third track, "Jingle Bells Pt.1", now play?

rippolito · « **Reply #37 on:** August 26, 2020, 07:38:45 pm »

RoderickGI,

I just re-downloaded 'Ring Out Solstice Bells' playlist from Cloudplay, and it plays: every song, including Jingle Bells Pt. 1, has bitrate, duration, file type, and sample rate all present.

I would not have expected that information would come and go like it does.
Ron

rippolito · « **Reply #38 on:** August 26, 2020, 07:46:32 pm »

I take it back: Jingle Bells Pt. 1 does not have a bitrate, and of course, it does not play.

When I moved it down to the second song in the playlist, the first song played, and then I got 'something went wrong with playback' when it went to the second song. Then, I manually moved it to the third song, and it played fine.
Ron

JimH · « **Reply #39 on:** August 26, 2020, 08:33:03 pm »

Can you find another playlist that has the same problem?

RoderickGI · « **Reply #40 on:** August 26, 2020, 08:42:27 pm »

I just tested downloading the Cloudplay Playlist again and successfully played that. Then tried directly from Cloudplay again and successfully played it. But in each case all the files have a [Duration] value, but no [Bitrate], [Sample Rate], [Bit Depth] or even [File Type] values.

I was just playing locally for the above tests. So I repeated them playing to the BubbleUPnP Renderer, which was also successful.

Given the previous discussion, I'm back to thinking it has something to do with your Renderer.

Run the DMRA against your Renderer and post the report.

rippolito · « **Reply #41 on:** August 26, 2020, 08:59:13 pm »

JimH,

Try this one...

- Author - JaxtheRogue
- playlist - 2015 Review - Pedestrian At Best

Songs have no bitrate, file type, or sample rate.

When I play them via my 'local player', they play successfully. When I submit them to my sms-200 DLNA renderer, they fail.
Ron

AndrewFG · « **Reply #42 on:** August 27, 2020, 05:20:59 am »

Quote from: rippolito on August 26, 2020, 08:59:13 pm

Songs have no bitrate, file type, or sample rate.

Sorry but I have rather lost track of this discussion. Could you please explain to me simply (again) what exactly are you looking at that tells you the track has no bitrate etc? Are you looking at something onscreen / in a log / on a network analyzer, or what?

rippolito · « **Reply #43 on:** August 27, 2020, 05:34:19 am »

Andrew,

In post #15, if you look at the ping file I posted, it is a screen snap showing the first few songs in the playlist, the first of which has no bitrate.

Post #18 is an excerpt of entries from log files for the first two songs in the playlist, showing no sample rate, no bit rate, or no file type.
Ron

AndrewFG · « **Reply #44 on:** August 27, 2020, 06:03:02 am »

^
Thanks for the quick response.
So I think you are saying that there are really two issues rather than one ("track won't play") -- namely:

In MC CloudPlay playlists, some tracks do not display a file type, bitrate, (or icon)
When you try to push those tracks to a remote Renderer, then depending on the Renderer type, they might not play

I think that issue #2 ("track won't play on my renderer") is NOT the actual problem; it is a symptom only. The real issue is #1 ("MC doesn't show track meta data").

For me it is pretty obvious that if MC is pushing tracks to renderers without providing proper meta data, then many renderers will fall over. Indeed it is quite surprising to me that some people have found remarkable renderers that are able to play such tracks.

In short, we need to focus on Issue #1 ("MC doesn't show track meta data").

---

EDIT: and BTW the real real issue with #1 is not the matter of MC not knowing/showing the bitrate -- it is the fact that MC does not know/show the media type. Put simply it means that when the renderer does its HTTP GET for the track, then the MC server will not provide a Content-Type header. And therefore the renderer won't know what media type it is supposed to play.

Not providing a Content-Type header is non compliant with the the UPnP server specifications. Obviously some renderers are better than others at handling non compliant servers. For example some renderers will look at the file extension on the URL (in this case ".flac") and deduce a media type from that, and others might download and analyze a piece of the media itself. But it is actually the obligation of the MC server to provide a Content-Type..

rippolito · « **Reply #45 on:** August 27, 2020, 08:25:39 am »

Andrew or Jim or RoderickGI,

Does JRiver have a setting that says 'if a song fails to play, skip to the next one and play that one'? If it does, how and where does one set it?
Ron

bob · « **Reply #46 on:** August 27, 2020, 09:43:54 am »

Quote from: AndrewFG on August 27, 2020, 06:03:02 am

^
Thanks for the quick response.
So I think you are saying that there are really two issues rather than one ("track won't play") -- namely:
In MC CloudPlay playlists, some tracks do not display a file type, bitrate, (or icon)
When you try to push those tracks to a remote Renderer, then depending on the Renderer type, they might not play
I think that issue #2 ("track won't play on my renderer") is NOT the actual problem; it is a symptom only. The real issue is #1 ("MC doesn't show track meta data").

For me it is pretty obvious that if MC is pushing tracks to renderers without providing proper meta data, then many renderers will fall over. Indeed it is quite surprising to me that some people have found remarkable renderers that are able to play such tracks.

In short, we need to focus on Issue #1 ("MC doesn't show track meta data").

---

EDIT: and BTW the real real issue with #1 is not the matter of MC not knowing/showing the bitrate -- it is the fact that MC does not know/show the media type. Put simply it means that when the renderer does its HTTP GET for the track, then the MC server will not provide a Content-Type header. And therefore the renderer won't know what media type it is supposed to play.

Not providing a Content-Type header is non compliant with the the UPnP server specifications. Obviously some renderers are better than others at handling non compliant servers. For example some renderers will look at the file extension on the URL (in this case ".flac") and deduce a media type from that, and others might download and analyze a piece of the media itself. But it is actually the obligation of the MC server to provide a Content-Type..

bitrate isn't used by most renderers. MC doesn't even send it by default because we ran into some renderers that parse it wrong. File type must be provided. No idea why it isn't for those entries. Perhaps they are old entries before some DB change.

rippolito · « **Reply #47 on:** August 27, 2020, 01:02:28 pm »

So in the context of Cloudplay playlists...

Do we think the parameters (for example, file type) were missing when the playlist was originally uploaded?
[Do we think the parameters were there originally, and got omitted somehow when mirroring the playlists among the cloud servers?/li]

Ron

bob · « **Reply #48 on:** August 27, 2020, 04:19:11 pm »

So we've determined the issue.
The cloudplay API isn't returning the missing information for any of the files.
At some point some of the files are likely getting analyzed to fill that info in which is why some of them have it and others don't .
We'll likely update the API in version 27 but there is a simple workaround.
Just select the cloudplay files, right-click on them and do library tools->update library from tags.

rippolito · « **Reply #49 on:** August 27, 2020, 05:02:41 pm »

Bob,

Now that is a workaround.

I updated a single file and a collection of files, and both were successful.

Thanks to you, Roderick, and Andrew for helping to isolate what the real problem was.
Ron

INTERACT FORUM

Author Topic: Intermittent streaming via DLNA from my iMac (Read 3765 times)