When streaming a playlist/album to DLNA devices and then trying to stop the playback on the device directly or via a different controller (Home Assistant in my case) Symfonium skips to the next song instead of actually stopping the playback. Same when changing the input on the other device (which might or not be the same issue). Pressing Pause/Skip on the other hand works fine, so I guess general communication between Symfonium and the receivers is working, just ‘Stop’ misbehaves.
I tried two different hardware players (B&O, Arylic (Linksys)) controlled via Home Assistant as well as KODI on a PC set up to act a DLNA receiver and controlled directly. So I guess this being an issue on the player side can be ruled out.
Should be fairly easy to replicate by setting up a KODI instance as DLNA receiver one some device.
The log file should show the result of pressing stop a few times in KODI running on a PC, resulting in skipping to the next song instead of stopping playback.
BTW: Bought this wonderful app a few weeks ago and this literally was the only annoying glitch I encountered since then. Awesome!
This is the joy of UPnP, Symfonium have no way to know why the renderer goes to stopped status.
And stopped status is the indicator that the track is ended and the next one should be started.
The stop could be caused by anything and so the app continue the queue as it’s frequent that people want to skip a track, more than people stopping using another controller, they usually pause.
Yeah, I mean when you both have a play and pause button it doesn’t really matter obviously…
I didn’t want to complicate the issue description, so I broke it down to “pressing stop doesn’t work”. The actual practical issue is that occasionally when you change the input on some other device, shortly after (or sometimes later) playback switches back to the prior Symfonium playlist, which obviously is unwanted.
I don’t know any intrinsics of UPNP/DLNA, but dealing with stuff maysel that includes coming up with all kinds of heuristics, maybe you have some clever idea even if the protocol throws a bunch of obstacles in your way.
The problem is not only the heuristics, as I said the most common case is users wanting a quick next, since it can happen at anytime.
There’s also plenty of broken devices who restart just because Symfonium request the current status.
There’s no one solution to the problem.
If you change input on the device it also depends what it will answer as stopped or keep answering the loaded media on the UPnP client.
So provide logs for exactly your issue with the appropriate details, and I’ll see if there’s something I can do.
All good. No need to come up with a solution in a forum reply, maybe it even actually is impossible. No problem.
Just keep this in mind, occasionally think about it, and maybe in a few days you have an idea how to differentiate between the potential cases in a reasonably safe way, that’s what I meant when saying heuristics. Or maybe not. At least ln my experience super quick ‘that cant’t work’ impulses proved wrong often enough to not dismiss anything quickly anymore.
Logs probably won’t show anything else than the one I sent you from the KODI test. I’ll check again and let you know if they do.
This is a known issue since my other app Yatse that is 13 years old
I’ve think a lot about it and as said there’s no perfect one fit all solution. UPnP is not a protocol build to support multiple controllers.
So as said provide the logs for the exact issue showing what the change of output on your receiver shows with the details about exactly what you do in those logs so I can see if that specific case can be handled.
For the stop handling it’s a deliberate choice to not apply heuristics as those heuristics can’t be applied to skip next on external remotes and this is the main need over external stops.
I uploaded another logfile. The issue is actually worse then I thought originally. Happens even when pressing pause in Symfonium before switching input on the speaker.
This is what happened during the log recording
Play an album (Purple Rain/Prince in the example) in Symfonium on a DLNA speaker (B&O Beosound here) > First song starts to play (Let’s Go Crazy)
Pressing Pause in Symfonium > Playback Stops
Switching to a web radio station In the B&O app > For ~1sec input actually switches to the radio channel, then Symfonium comes back on. It resumed playback with the second title of the album (Take Me with You) without any other user input than switching to radio in the B&O app.
This is obviously unwanted behavior. In effect It’s practically impossible to convince Symfonium to stop playing the album until it reaches the end or the queue is cleared manually.
The same issue occurs when switching to other inputs, when using a different controller app (Home Assistant) and also on another device (Arylic A30).
On the other hand after initiating the DLNA album playback in Jellyfin instead of Symfonium, switching to another input on the speaker works without hitches. Not even stopping playback before switching is necessary in that case.
So it’s safe to say this A. is a Symfonium related issue, and (most importantly) B. can be addressed.
After starting a album/playlist playback on a DLNA speaker it is impossible to switch input on the speaker until Symfonium reaches the end of that album/playlist no matter what. After switchinh input Symfonium even automatically resumes playback that has been stopped in Symfonium itself before when switching input on an external device.
Doing the same thing in Jellyfin on the other hand works perfectly fine. So there is obviously something wrong with how Symfonium handles this.
Debug mode was of course enabled for the log files. What they show is all they log when executing the stepps mentioned above.
Logs aside, precise steps to reproduce the issue have been provided above. if you actually wanted to investigate the issue, you could simply do so by following the three simple steps in my post above. If you do that, you will understand the problem, which is very, very obviously wrong.
I want to switch input on an external speaker without having to care about stopping/pausing/whatever playback in Symfonium itself first at all.
Which works perfectly fine when starting playback in Jellyfin! So obviously there is a way to handle this in a user friendly way,
Imagine situations where one starts an album in Symfonium, then goes to a different room without their phone and from there wants to switch input on the speaker. That’s virtually impossible when playback was started with Symfonium because it keeps getting in the way until it reaches the end of its playlist.
Again: doing the very same thing with Jellyfin directly works perfectly fine, so this obviously can be handled better.
And resuming a paused playback when switching input on an external device is also a deliberate choice? If so, why do you do that only on DLNA speakers and not e.g. on Chromecat devices?
Come on, man, that’s ridiculous. This is obviously either a bug or the most stupid “deliberate choice” I have ever heard of. Including a bunch of very stupid choices I made myself before users convinced me to rethink them in my software…
BECAUSE AS EXPLAINED UPNP IS A SHITTY PROTOCOL THAT DOES NOT SUPPORT MULTIPLE CONTROLLING ENDPOINTS ?
You are seriously a pain, so my need are stupid right? I mean why the fuck would my wife want to be able to click next on a remote to skip a song when I started playback from my phone?
I guess my wife is stupid too? And my kid? And quite a few users?
You have no idea how UPnP works, you still refuse to provide the proper logs to see if I can workaround for your device but I’m the stupid one ?
If you had provided the logs and there was no workaround I could eventually have added an option for Symfonium to act as your stupid need (It’s stupid because it’s not mine right?).
But since you do not and insult me I’m not sure I’ll loose time doing that …
Symfonium on itself resumes playback and by doing so and forces the speaker to switch back to DLNA input.
Under no thinkable logic in this universe is that what should happen. No matter how many gripes you have with the UPNP protocol, that’s just not what should happen.
Try to think this from the users end not from your - understandable - gripe with some protocol. It’s just wrong. Period.
Provide the fucking asked logs if you want to continue this discussion because you are ridiculous …
You can’t just ignore fact and other users needs.
UPnP have states playing / paused / stopped. And that’s pretty much all.
If you press next on the physical remote of the renderer, it will go to stopped. Stopped is the indicator that current track is ended and next track should be started, and that what Symfonium do.
And why it does that, BECAUSE THAT’S MY FUCKING NEED, AND MY WIFE NEED AND THE NEED OF QUITE A FEW USERS.
So you have proven already that only you have the knowledge that what you say is the only truth because your need matters most.
But welcome to the real world, no it’s not wrong it’s a fucking choice, and your needs are not the only need …
TL;DR;
Start to read, apologize for your behavior and insulting me, provide the logs and I’ll add the option for your need if I can’t workaround as said since the start.
Else go … and use Jellyfin.
