INTERACT FORUM

Please login or register.

Login with username, password and session length
Advanced search  
Pages: [1]   Go Down

Author Topic: Strange behaviour using MC as a DLNA renderer  (Read 955 times)

DJLegba

  • Citizen of the Universe
  • *****
  • Posts: 995
Strange behaviour using MC as a DLNA renderer
« on: March 06, 2019, 08:17:03 am »

MC 24.0.75 (64-bit)

I am a new subscriber to the Tidal streaming service, and I was very happy to find that the BubbleUPnP app on my Android phone can send Tidal content to MC via DLNA. With the DLNA renderer configured for gapless playback in BubbleUPnP, the playing now list on my MC computer shows the current track and the next. MC DSP settings work, and the brilliant app will let me mix content from Tidal and my MC library in the queue or in a playlist if I want. So far, fantastic.

On my ancient iPad I use the Lumin app to send Tidal content to MC, but in this case I need the BubbleUPnP server running on my MC computer, with the renderer configured for Open Home compatibility (so it shows up in the list of "Lumins").

Tidal via MC is working far better than I expected. To say I'm pleased would be an understatement. However, I've noticed some strange behaviour.

1. If I stop playback from Bubble and initiate playback of local content using JRemote, or directly on the MC server, the Tidal tracks queued by Bubble will resume playing. I must clear the playlist using Bubble after stopping playback. Not a big deal, but this isn't how MC normally works. Normally selecting something new clears the queue. I am aware that JRemote can be configured to append to the queue by default, but I have it configured to play the selected item. Note that this happens with or without the BubbpleUPnP server running.

2. While streaming something from Tidal, I purchased a couple of downloads and copied the files into my library. MC's auto-update found them, but both albums were missing cover art. I clicked Get from Internet, and right away the "find" dialog showed the covert art file that was in the album's folder. However, no matter what I did, cover art would not display in any of MC's views. I've never had this problem before. I restarted MC and it picked up the cover art right away.

3. When using MC as a DLNA renderer it closes from time to time. I leave MC running 24/7 and it has been very stable, so I turned off logging a long time ago. However, now that I've started pushing content from other sources, it has quietly closed a few times. I've enabled logging again, but the problem hasn't happened since then.

I've seen a lot of requests to get Tidal and Qobuz working with MC. It's likely that many people want a tighter integration than my solution, but sending Tidal content to the DAC via MC - without using the WDM driver - is certainly good enough for me. Are the issues I've mentioned just things associated with DLNA that I should have known about (a quick search turned up nothing), or are they things that could be addressed in a future release of MC?
Logged

RoderickGI

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 8186
Re: Strange behaviour using MC as a DLNA renderer
« Reply #1 on: March 06, 2019, 03:42:08 pm »

Interesting. I'm actually surprised it is working as well as it is for you.

I am wondering if there is any format conversion in that audio chain, and what exactly arrives at MC. Also, MC DSP works with a Tidal source via DLNA? When it is receiving audio via DLNA as a Renderer? Normally MC applies DSP as a server, and not as a Renderer, as that could result in double DSP effects. I guess DSP can be applied when audio is received via the WDM though, so it is probably similar with DLNA. But unexpected. Plus it mixes tracks from Tidal via DLNA with tracks from a local source file, in one Playlist? Amazing. Also completely unexpected.

1. I noticed something like that in playing with just two MC instances and BubbleUPnP. BubbleUPnP would start playing again after I stopped playback from it, and I tried to play something from another source. I didn't try to define exactly when it happened as I was just investigating options.

2. MC does seem to take a while to find some Cover Art, sometimes, but eventually does. Rather than using "Get from internet", try using the "Quick Find In File / Cover Art Directory". It might update the view immediately I think. I would have expected a View refresh to show the Cover Art though. When it won't show before a restart, does the correct reference to the art exist in the tags?

3. I saw this as well, when I was playing with DLNA on my network. It also seemed to happen after I finish playing and just left the HTPC/Server to sleep. As I wasn't doing controlled testing I didn't investigate further, and a recent update seems to have stopped the problem. But I haven't tested much since. I would say, collect the logs and see if there is anything obvious.


An interesting solution, although I don't like all the moving parts, particularly with DLNA, which I still consider as flaky, unless you get a set of devices and software tested to work well together. Even then, any software or firmware update seems to cause issues down the track.
Logged
What specific version of MC you are running:MC27.0.27 @ Oct 27, 2020 and updating regularly Jim!                        MC Release Notes: https://wiki.jriver.com/index.php/Release_Notes
What OS(s) and Version you are running:     Windows 10 Pro 64bit Version 2004 (OS Build 19041.572).
The JRMark score of the PC with an issue:    JRMark (version 26.0.52 64 bit): 3419
Important relevant info about your environment:     
  Using the HTPC as a MC Server & a Workstation as a MC Client plus some DLNA clients.
  Running JRiver for Android, JRemote2, Gizmo, & MO 4Media on a Sony Xperia XZ Premium Android 9.
  Playing video out to a Sony 65" TV connected via HDMI, playing digital audio out via motherboard sound card, PCIe TV tuner

DJLegba

  • Citizen of the Universe
  • *****
  • Posts: 995
Re: Strange behaviour using MC as a DLNA renderer
« Reply #2 on: March 06, 2019, 04:36:48 pm »

I am wondering if there is any format conversion in that audio chain, and what exactly arrives at MC.

MC reports 44.1 kHz 16bit 2ch from source format FLAC. I assume the Bubble app is just forwarding FLAC to the MC DLNA renderer.

Also, MC DSP works with a Tidal source via DLNA? When it is receiving audio via DLNA as a Renderer?

It certainly does. I just tested it again.

Plus it mixes tracks from Tidal via DLNA with tracks from a local source file, in one Playlist? Amazing. Also completely unexpected.

The Bubble app is grabbing the "local" files from the MC UPnP server and sending them back to the MC DLNA renderer. Bubble is doing the magic. I'm sure you could build a Bubble playlist mixing source material from Tidal, Qobuz, Google, and your own UPnP servers.

2. MC does seem to take a while to find some Cover Art, sometimes, but eventually does. Rather than using "Get from internet", try using the "Quick Find In File / Cover Art Directory". It might update the view immediately I think. I would have expected a View refresh to show the Cover Art though. When it won't show before a restart, does the correct reference to the art exist in the tags?

The files contained embedded cover art already. These weren't ripped files - they came from 7digital.com with the correct album name, artist, track names, etc. I was able to make some tag edits (changed the genre, added the composer) and run the "Analyze Audio" tool. I tried refreshing the view a few times. I'll test this again the next time I buy a download.
Logged

DJLegba

  • Citizen of the Universe
  • *****
  • Posts: 995
Re: Strange behaviour using MC as a DLNA renderer
« Reply #3 on: March 06, 2019, 04:53:37 pm »

BTW, I also tested DSP when Bubble sends to MC which then sends to another DLNA renderer (a Muso Qb) and it works too. Although Bubble can send directly to the Muso Qb, sending it to the Muso via MC is necessary if you want to apply DSP.
Logged

RoderickGI

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 8186
Re: Strange behaviour using MC as a DLNA renderer
« Reply #4 on: March 06, 2019, 06:28:43 pm »

The Bubble app is grabbing the "local" files from the MC UPnP server and sending them back to the MC DLNA renderer. Bubble is doing the magic.

Ah. That makes more sense. I thought MC was combining the tracks.

Good information. Thanks.
Logged
What specific version of MC you are running:MC27.0.27 @ Oct 27, 2020 and updating regularly Jim!                        MC Release Notes: https://wiki.jriver.com/index.php/Release_Notes
What OS(s) and Version you are running:     Windows 10 Pro 64bit Version 2004 (OS Build 19041.572).
The JRMark score of the PC with an issue:    JRMark (version 26.0.52 64 bit): 3419
Important relevant info about your environment:     
  Using the HTPC as a MC Server & a Workstation as a MC Client plus some DLNA clients.
  Running JRiver for Android, JRemote2, Gizmo, & MO 4Media on a Sony Xperia XZ Premium Android 9.
  Playing video out to a Sony 65" TV connected via HDMI, playing digital audio out via motherboard sound card, PCIe TV tuner
Pages: [1]   Go Up