cls-nebadje writes

When upplay reaches the end of the playlist without repeat or similar, it wraps and starts from the beginning of the playlist but only the first few seconds and skips to the next track. The interesting thing is that the regular playlist progressing seems to work. It simply chokes on the end.

Most probably this is caused by upplay which issues a play on the first track and tries to enter pause immediately after but ignores the transitioning state of the media renderer.

When looking at the output of the media renderer I see the following:

DEBUG dmr_output.cpp:422: EOS
DEBUG dmr_output.cpp:200: AVT uri: http://192.168.1.49:49155/content/media/object_id/153074/res_id/0/ext/file.flac
ERROR service.cpp:72: Action failed with: upnp/dmr/transport_service.cpp(616): Throw in function void dwe::upnp::dmr::TransportService::ActionPlay(dwe::upnp::Action&, dwe::upnp::ActionRequest&, const dwe::upnp::Action::Arg::In::Map&)
Dynamic exception type: boost::exception_detail::clone_impl<dwe::upnp::dmr::Output::StopError >
std::exception::what: std::exception
[dwe::tag_err_code*] = 701
[dwe::tag_err_desc*] = Pause not available in state TRANSITIONING.

This can be interpreted as following: - The renderer detects end of stream and enters STOPPED state - upplay - even if at end of playlist - issues a play command with the first track as argument - then it tries to pause even if the DMR is in TRANSITIONING state (due to the previously issued play command), which then fails of course, because pause is not allowed during TRANSISTIONING - For whatever reason upplay continues with the next track which results in the same behaviour

I recorded a desktop video which illustrates the above behaviour pretty clearly: [upplay-end-of-playlist-bug.ogv.zip](https://github.com/medoc92/upplay/files/214707/upplay-end-of-playlist-bug.ogv.zip)

Possible solutions would be: Handle TRANSITIONING properly or just keep the playlist at the very last position. Handling TRANSITIONING properly is recommended, but using the play command to "rewind" the playlist seems a bit weird to me - this should be implemented in the GUI/control point directly IMHO.

In case you should require more information, just let me know.

Regards Uli

medoc92 writes

What renderer is this ? Looks like software as you show the log. Is it somehow available for testing ?

Actually, I would be more intested by the contents of the log in the terminal than by the video :)

Please either execute upplay like upplay > /tmp/trace 2 >&1, or copy/paste the term contents.

cls-nebadje writes

The renderer is proprietary and unfortunately closed source, but I can assist you as I have access to it. Yeah, of course, I prefer logs too, but the video nicely shows the effect which would have been difficult for me to describe ;) So here we go, the behaviour happens after the seek. The environment is Upplay 1.2.4 libupnpp 0.14.1 libupnp 1.6.17 which is a bit outdated on this machine but I’ll switch to the github repo in the meanwhile. [upplay.log.txt](https://github.com/medoc92/upplay/files/222199/upplay.log.txt)

Here’s the log from the latest build w/ your github sources: Upplay 1.2.5pre1 libupnpp 0.14.1 libupnp 1.6.17 [upplay-1.2.5pre1.log.txt](https://github.com/medoc92/upplay/files/222208/upplay-1.2.5pre1.log.txt)

medoc92 writes

I agree that the video helps in understanding what happens :)

I think that your error message is wrong by the way, and that the error is in response to a Play command, not Pause, this is not important of course, but it makes things a little less crazy.

I sort of see what is happening, but not completely. I have pushed a new version with a few changes and more messages. Could you please recompile the new git code and produce a new log when you have a moment ?

This is the first time I get a "transitionning" status from a renderer. The thing I wonder about is why I get a 701 there and not at other times, when playing the first track by example ?

cls-nebadje writes

Hi Jean-François,

yeah, I saw that - this debug message is definitely wrong and should read "Play not available in state TRANSITIONING" - that’s a flaw on our side which confused both of us ;) Excuse me. Thanks for pointing that out. Due to this I reviewed the DRM’s state machine today, making sure that you don’t have to debug stuff we messed up - but it seems to be OK.

Using commit 1cc4561c98c61d8377a681073f657e45455c3ac0 upplay doesn’t exhibit this problem anymore. Great (fingers crossed)! For completeness I attached the log of such a session.

Regards and thanks for being so responsive! Uli

medoc92 writes

Hi Uli,

No problem about the message, I had no doubt that this was a wrong message string.

I’m glad that the small changes I made fixed the issue. My problem with this kind of thing is that I don’t really have a collection of renderers to test with … Things still seem to work with Kodi and my upmpdcli (in avt mode), so let’s cross fingers.