seeking doesn't seem to work

[addadi]

when seeking inside track the playback is stopped and spotify is disconnecting playback device.

I HTTPstreamer.cpp:455: HTTP close 22 I HTTPstreamer.cpp:440: got HTTP connection 22 I HTTPstreamer.cpp:207: HTTP received => GET /stream?id=bbbb3054b6be_1 HTTP/1.1 User-Agent: Rygel/0.42.1 DLNADOC/1.50 UPnP/1.0 Accept-Encoding: identity Connection: Keep-Alive Host: x.x.x.107:33855 icy-metadata: 1 transferMode.dlna.org: Streaming

I HTTPstreamer.cpp:309: HTTP response => HTTP/1.1 200 OK contentFeatures.dlna.org: DLNA.ORG_OP=01;DLNA.ORG_CI=0;DLNA.ORG_FLAGS=01700000000000000000000000000000 transfermode.dlna.org: streaming Server: spot-connect Content-Type: audio/flac Connection: close

I HTTPstreamer.cpp:455: HTTP close 22 D MercurySession.cpp:222: Executing Mercury Request, type SEND [20:13:32.661495] ActionHandler:560 [0x7fdee9ec9a68]: uPNP stopped I spotify.cpp:459: Disconnecting Audio/Video playback on xxxx+

[20:13:32.661644] AVTStop:204 [0x7fdee9ec9a68]: uPNP stop (cookie 0x1e) I HTTPstreamer.cpp:163: HTTP streamer bbbb3054b6be_1 stopped I HTTPstreamer.cpp:140: deleting HTTP streamer bbbb3054b6be_1 I MercurySession.cpp:100: Disconnecting mercury session I PlainConnection.cpp:187: Closing socket... E MercurySession.cpp:41: Error while receiving packet: Error in read I spotify.cpp:576: disconnecting player Audio/Video playback on xxxx+ [20:13:33.660019] ActionHandler:560 [0x7fdee9ec9a68]: uPNP stopped

[philippe44]

Thank you for being my first user !!! Can you tell me exactly the type of UPnP player you are using? And can you give me a bit more log, from the beginning of the playback session. I think I know why but I need the whole story. BTW, seeking is the most complicated part of this bridge so I was expecting issues but there is a fair bit of solutions ready to be added in case of problem.

[addadi]

Thanks for developing this! But I guess I'm not the first user, I others have stared this before. Here's the full log spotupnp.log

I'm using Rygel as upnp renderer for tests. btw: I know seeking is the hardest part. I'm also trying to debug this - https://github.com/mas94uk/upnpTube btw 2 : can you explain a little bit the architecture of spotupnp?

[philippe44]

Well, almost and you are certainly the first to open an issue :-)

I'm not sure what you exactly want to know about the architecture. It's a c/c++ app, standalone.

The UPnP side is in charge of detecting devices and monitoring their state/track progress as well as sending all play/pause commands. The Spotify side creates virtual SpotConnect players and receives commands from Spotify controller. It performs audio decoding and re-encoding as well as spawning an http server for each UPnP player to grab audio.

The Spotify side is really divided into, the un-modified cspot which is purely a Spotify engine and a bridge part which is here to transcode commands and status between the two sides and runs the actual http servers and codecs, one per UPnP player.

[philippe44]

Thanks for developing this! But I guess I'm not the first user, I others have stared this before. Here's the full log spotupnp.log

I'm using Rygel as upnp renderer for tests. btw: I know seeking is the hardest part. I'm also trying to debug this - https://github.com/mas94uk/upnpTube btw 2 : can you explain a little bit the architecture of spotupnp?

It's an empty log

[addadi]

sorry. here's there correct file SpotConnect.log

[philippe44]

oh - are you seeking immediately after you started playing or are you waiting a few seconds (say 10)?

[addadi]

perhaps in this log example I've tried it quite instantly, but I've tried it now in several scenarios and there several unexpected issues that are happening:

1. if I connect to the upnp renderer during playback, spotify controller app is playing on the phone but no sound is heard on the upnp renderer
2. seeking is disconnecting the upnp renderer and then when I manually reconnect it, it sometimes work, sometimes doesn't
3. After seeking if playback continues, the spotify app looks like it's playing at a different time than the renderer. i.e. the app is playing at 1`:30 of the track, but the renderer playing is at 0:10 There are several other issues, unrelated to seeking I encounter while test the seeking function. should I open a new issue for each?

[addadi]

There's another interesting point. I'm heavily testing three different renderer: rygel, kodi and gmrender-resurrect. they all behave differently. most stable is gmrender-resurrect - seeking is working quite good. so it might be a renderer problem and not SpotConnect issue after all

[philippe44]

That's the difficulty with UPnP. The standard is very poorly respected and every implementation is different

[philippe44]

Can I close this one?

[addadi]

I guess so. The issue is still there, but I'm not doing any active actions to debug it right now. when it works, it works. Thanks!