Print

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

[mwillems]

I can't seem to reliably "pull" video via DLNA from a JRiver DLNA server.  

I've been fooling around with ARM single board computers, which (obviously) can't run a full instance of MC.  I'm currently trying to setup an ODROID C1 as a media renderer/thin client for an old not-so-smart TV in the kitchen.  The C1 can run either android or linux, but the problem I'm seeing seems to be the same on both platforms.  

When I try to pull video using a UPNP/DLNA client (I've tried bubbleupnp and xbmc/kodi) from my MC DLNA server, I get video for a little while, but then a black screen.  Audio continues for a while, but then the whole thing quits and I'm thrown back to the menu.  The amount of time it takes to fail varies from a few seconds to ten or twenty minutes, but it always fails eventually.  The inability to pause the video or stop and resume makes this hard to work around.  

I tried playing the same files locally without transcoding, and they played.  I also tried using convert format to transcode to the same target format MC is streaming, and tried playing the converted file locally, and it worked fine.  So it's not that the ODROID can't play the video/the format MC is sending.

Since the C1 can run android, I also tried streaming the same files using Gizmo on the C1 with an android install, and that seems to work fine, so my server is capable of transcoding and streaming the file successfully to the C1 outside of the DLNA/UPNP framework.

That seems to isolate the issue to something in the UPNP/DLNA communication going on between MC and the UPNP/DLNA renderer.  Given that I get the same results with multiple different renderers, I suspect there's something wrong in my MC configuration.

So far I've tried:

1) Different transcoding profiles; I tried all the 264 and mpeg options (no difference)
2) Different MC server options; I tried toggling each of the settings relevant to video one at a time (no difference)
3) Playing audio (works fine).

Any thoughts or suggestions would be welcome.  

Obviously, I can just use gizmo in a pinch, but I'd prefer not to run gizmo/android on the box as that shuts down using a DLNA control point elsewhere to control the box, Gizmo's IR remote support is less than ideal, and using android with a mouse is kind of wonky.  

Do folks have good success pulling video from MC via DLNA?  Any recommended renderers that will run on Linux and have good ir remote control?  

[mwillems]

So I spent most of the afternoon working this one and found a (admittedly bizarre) solution, I thought I'd post it in case this rings any bells for the JRiver devs or anyone else is experiencing a similar issue.

So I have an MC server that has the three DLNA functions ticked (server, renderer, and controller), but I also have several client PCs that also had DLNA controller functionality enabled so that I could control other MC clients from a central location (tremote only works from client to server, but not client to client).  

The solution to my problem was (strangely) to turn off the DLNA controller option in JRiver on every box other than the server.  After spending some time looking at the media network log during playback, I noticed that the black screen/connection loss seemed to coincide with a log event from one of my JRiver client PCs with DLNA controller enabled (usually an M-search).  It didn't happen every time, but the black screens seemed to always coincide with one of those log events.  So, on a hunch, I disabled DLNA controller on the non-server boxes.  The problem immediately vanished, and I managed to play two movies back to back all the way through.

So it looks like having more than one MC instance running as a DLNA controller was confusing/interrupting the renderer somehow?  I know next to nothing about UPNP or DLNA, so I'm sure that's not the technical term for it, but disabling all but one JRiver DLNA controller made the problem vanish, and reenabling makes the problem return.  

Interestingly, some other upnp/DLNA devices in my house are now working better too.  I had been experiencing similar occasional playback interruptions on a Raspberry Pi-based UPNP audio renderer (using MPD and upmpdcli) that now seem to be gone as well. I had just chalked those up to wifi flakiness (and or RPi flakiness), but I've managed to play several albums back to back on the Pi without an interruption which is unusual.  

It seems that, at least with my silly SoC homemade renderers, two JRiver instances working as DLNA controllers on the same network was one too many.  If the devs are interested in running this down, I'm pretty sure I can reproduce the issues, but I'm just happy to have found a fix.

[AndrewFG]

Hmm.

Obviously the more Control Points (CP) you have active, the more traffic they are going to create a) with servers (DMS), and b) with renderers (DMR). If the number of CP, DMS, DMR entities is N then the number of cross connections could be of the order of N^2.

You mentioned the M-Search discovery traffic, and this, coupled with the associated Upnp description Http traffic will be a main culprit. Plus it is likely that CPs will Subscribe to Eventing on DMR and DMS entities, and the respective Subscribe, Renew, and Notify traffic will ensue. Furthermore it is likely that some CPs may be polling the DMRs play & position status, and this will generate traffic too.

It is not clear from your symptoms whether MC (or the HTPC) is hitting a hard limit (e.g. max limit on concurrent TCP sockets), or whether it is hitting some kind of race condition between needed network resources, or whether it is just plain running out of juice..

[mwillems]

It is not clear from your symptoms whether MC (or the HTPC) is hitting a hard limit (e.g. max limit on concurrent TCP sockets), or whether it is hitting some kind of race condition between needed network resources, or whether it is just plain running out of juice..

I can provide the following additional data points: 

1)  Neither of my renderers appear to be approaching network saturation in these scenarios.  The ODROID is wired to a Gb ethernet switch and a conky graph shows utilization peaked around 10 or 11Mb/sec.   The RPi is on WiFi, which is a little flakier, but I can usually get about 20 or 30Mb/sec throughput on it with sustained file transfer.  Spot checking when streaming music, it looks like a few Mb/sec at most. 

2) Neither renderer is getting particularly close to max CPU usage.  During video playback on the ODROID, I'm seeing one CPU core hitting 50% utilization (it's a quad core).  On the Pi, during audio playback the CPU is hitting 20% max.

3) My server PC does not have a ton of grunt (passmark of about 2000).  During transcoding, it seems to hit 100% CPU and stay there with occasional dips back down to lower utilization.  It looks like it stays at 100% utilization about 80% of the time during playback.  So it's possible that the server is almost out of grunt and the extra net traffic pushes it over the edge?  Next time I'm fiddling, I'll try using one of my gruntier PCs and see if that changes the situation (although server CPU utilization would not explain why audio streaming to the Pi was interrupted).

None of which decisively rules out any of your three alternatives, but I thought I'd offer the extra info I had on hand.  BTW your analyzer has been of immense help during my broader DLNA  troubleshooting process (especially for getting the Pi to work at step one).  Thanks for all your work on it!