Announce: UPnPBridge = integrate UPnP/DLNA players with LMS (squeeze2upnp)

[herve]

Ok I will. Thanks Philippe

Yes for your question about bubbleupnp. Pause/resume doesn't work with my renderer... The track restarts from the beginning.

[PaulinPosset]

Ok I will. Thanks Philippe

Yes for your question about bubbleupnp. Pause/resume doesn't work with my renderer... The track restarts from the beginning.

I don't know what the Pioneer settings are but have you ticked the "LMS seeks on resume" box in the settings? The Uniti will also re-start every track, local and remote, after a pause unless this is set.

[PaulinPosset]

I remember now all the test we did Still scratching my head on this one. I have also to say that I have a better grip on all the various slimprotocol and upnp "variations" now so, whenever/if you have time, I could take a log of a "correct pause/resume" with a local file and a "wrong one with Qobuz" (with your configuration file and the buffer files -idx- generated ) ? I might be able to have a better idea this time and find the mistery that probably is in some of the flac headers variation

Will do. I use pcm as preferred format for local files but flacs do work correctly so I'll run some tests and post.

[herve]

I don't know what the Pioneer settings are but have you ticked the "LMS seeks on resume" box in the settings? The Uniti will also re-start every track, local and remote, after a pause unless this is set.

I also tried the naim settings with the "seeks on resume" check box ticked with no more sucess.

[philippe_44]

I also tried the naim settings with the "seeks on resume" check box ticked with no more sucess.

Oh ... this is really weird then as the "seek on resume" should always work on local file. There are cases where some streaming services do not support "seeking" and which case, the problem remains and is at LMS level. But the "seek on resume" is faking a repositioning request to LMS. So this is like a "new play", but with position"0" being where you paused (this is the way LMS works when repositioning: it does not tell the player "go here within the data you already have received", but it stops everything and sends a brand new file to the player that starts at the desired position).

The reason why I do not recommend this mode is that the repositionning is the memorized position +/- 1 second, so this is not perfect

[philippe_44]

Will do. I use pcm as preferred format for local files but flacs do work correctly so I'll run some tests and post.

Thank you. Another thing: do you know a UPnP control point that works with (eg) Qobuz and the same files (does minimserver or bubbleupnp works for you) ? I you find one, do you know how to take wireshark traces of the exchanges ? No need to analyze them, I will do that, but if there is one example working, I could see what they do. I searched a bit around minimserver and they had the same problem a while ago but they solved the way I did it (I mean many players were not pausing properly, now most do, it was about setting some flags that should not be really set for flac, but we all did and it worked ... expect in my case for a few players)

[edit]: I've re-read and re-read the DLNA spec and there are 2 options that might be tested. You must be sure that 'LMS seeks on resume' (= seek_after_pause set to 0 in XML file) is disabled for a valid test. They are variants of the DLNA configuration that I don't think would make a difference, but things seems to be a bit unclear (at least for me) when flac is concerned. I think you are using Windows, so here they are (must either be renamed squeeze2upnp-win.exe and put in the plugin Bin directory, or manually started from anywhere with a good configuration file). Sorry to ask for all these tests, I would gladly make them if I had the right equiment

https://dl.dropboxusercontent.com/u/...-win_00217.exe
https://dl.dropboxusercontent.com/u/...-win_00017.exe

for info, there are 2 option for DLNA players to manage 'pause'

1- by keeping the TCP connection open but 'stalling' it until resume requested
2- by closing the TCP connection and upon resume, by re-opening a new one and asking the server to 'seek' to a given byte (or time) position

The server informs the player what it supports and by default I support both 1- and 2- (byte only, not time) but it seems that it might be a better idea to only do 1-, so the _00017 version does that (the _00217 version is a variant with a reduced byte seek authorization). It seems that the Uniti first stalls the connection, but then upon resume it closes it and then re-opens a new one starting at seek '0'

[PasTim]

The reason why I do not recommend this mode is that the repositioning is the memorized position +/- 1 second, so this is not perfect

I don't think this matters too much to most people, given that the music has been stopped.

[herve]

If you can still take a log of the incorrect resume, I will still have a look as I'm still trying to solve this problem - thanks !

I had a log which works fine :
upnpbridge.xml.txt
log-debug
And another not :
notok-upnpbridge.log.txt
notok-upnpbridge.xml.txt

hope it can help.
Thanks

[philippe_44]

I had a log which works fine :
upnpbridge.xml.txt
log-debug
And another not :
notok-upnpbridge.log.txt
notok-upnpbridge.xml.txt

hope it can help.
Thanks

Thanks - Can you just give me a bit of context of what was playing during the working and failed one ?

[herve]

First log, i could play pause/resume my local files (any format) and stream from tidal (flac), pause/resume as well, it worked perfectly. I can't explain why (i think i didn't change any settings) my second log failed with my local files and tidal, i did the same tests.