Podcast

[mrw]

I don't think the long press on pause is the issue. It's the fact that the Radio should show a menu when resuming a podcast episode. That doesn't happen. Don't know if that's even possible.

And it doesn't sound silly at all. I'm convinced this is not an easy task. Especially not when there are still a few different (user) interfaces to take into account.

I recognize some of the points you have made. Very difficult to track down.

Difficulties with getting into the "resume play" submenu may arise from the handling of very long podcast listings (>200 items). This impacts SqueezePlay, but not, as I recall it, Material Skin, because the latter limits the length of a listing it will fetch to, I think, 200 items. Or did.

I have attached a patch to LMS that seems to have been successful locally in handling the "long listings" issue. I am not going to try to explain it here, it is explained as best I can in the notes to the patch. It required careful scrutiny and understanding of how LMS/Squeezeplay sees things to figure out what was going on.

I remark that your Mac Power Users podcast certainly falls into this category. And the issue has been there for a long time.

[philippe_44]

I edited my previous post regarding this.

I do believe you are right with regard to what's happening. I think my issues have been with pause/time elapses/resume of a podcast currently in the playlist. If the time is a few minutes - fine, longer, say 1/2 hour+ maybe not. From memory, I got in the habit of noting the time before pause, and if resume failed, I would either ffwd to my remembered timestamp, or, go back to recently played, choose it again, then resume from last to recover.

The HTTP dropping after some time makes sense, but, the recently played-resume from last position works regardless of time. I went into my recents from weeks ago and resumed just fine.

Maybe if there was a "save spot" option instead of pause/resume it would help my use case? Say like '+' -> menu-> save spot or resume from saved spot.

But like I said, I am trained how to recover and it's not an issue, just trying to "what if" to help the op.

Jim

I was wrong, there is everything in place to resume to the paused position, if the stream is seekable which should be the case, so there is likely a bug somewhere. Could you set "(player.streaming.remote) - Player Remote Streaming Logging" to debug and capture a case where it fails?

[Redrum]

I was wrong, there is everything in place to resume to the paused position, if the stream is seekable which should be the case, so there is likely a bug somewhere. Could you set "(player.streaming.remote) - Player Remote Streaming Logging" to debug and capture a case where it fails?

ok, it is set, and I hit apply in settings. I don't have to restart LMS, do I? I have a podcast that I am halfway through and won't restart until tomorrow. I assume if it doesn't resume I just get you the log file?

Jim

[philippe_44]

ok, it is set, and I hit apply in settings. I don't have to restart LMS, do I? I have a podcast that I am halfway through and won't restart until tomorrow. I assume if it doesn't resume I just get you the log file?

Jim

Yes, no need to restart. If you can try to restart and it fails, that's where I'll take the log. If you have one today, I'll be able to have look in the evening

[philippe_44]

ok, it is set, and I hit apply in settings. I don't have to restart LMS, do I? I have a podcast that I am halfway through and won't restart until tomorrow. I assume if it doesn't resume I just get you the log file?

Jim

Also, if you set player.source log at at least info, you should see a log saying "Stopping remote stream upon full buffer when paused". It means that the player has been stopped and 1/the stream is seekable 2/the position was known.

BTW, is this a Group (from my Group plugin) that you are pausing? A Group will stay assembled for a certain amount of time only (default = 30 mins) and if you restart from a real player (e.g. a Radio) and not the virtual player form the WebUI or a controller like iPeng, then restart will not work correctly after the delay expired.

[Redrum]

Also, if you set player.source log at at least info, you should see a log saying "Stopping remote stream upon full buffer when paused". It means that the player has been stopped and 1/the stream is seekable 2/the position was known.

BTW, is this a Group (from my Group plugin) that you are pausing? A Group will stay assembled for a certain amount of time only (default = 30 mins) and if you restart from a real player (e.g. a Radio) and not the virtual player form the WebUI or a controller like iPeng, then restart will not work correctly after the delay expired.

I did not get the player.source suggestion until today, so I did not set it. I use your group plugin (thank you again) but podcasts are single room listening for me, so it's just single player. BTW this test was a receiver with a controller as the UI.

I had a resume failure this morning and have attached the log for today. I had paused it about 3PM EST yesterday, and tried to resume it this morning 7AM. When it failed it seemed to want to resume, and there might of been the "getting stream info" message (not 100% sure) but when it failed I got the full screen black block message "problem - could not connect to server <podcast name>". Then when I hit pause again (to retry resume), it started from the beginning. This is the failure case I have seen, and it does seem time dependent if I use pause/resume, but, using "play from previous position" does not seem to fail this way (to the best of my recall)

Like I said Philippe, it's not a big deal to me, especially now that I know what it is and how to recover. But, I know that a lot of us are the same, if something isn't right, we need to fix it, no matter how insignificant

Jim

[vco1]

Still testing this. The issue seems to be limited to this feed: https://www.relay.fm/mpu/feed

The cause might be that this feed has 570+ episodes (and counting). Resuming an episode does work from the Recently Played menu though. All actions on the SB Radio b.t.w.

Seems a bit strange to me that this behaviour is caused by the number of items in the feed, but I haven't looked at the code yet. So it might be logical.

[slartibartfast]

Still testing this. The issue seems to be limited to this feed: https://www.relay.fm/mpu/feed

The cause might be that this feed has 570+ episodes (and counting). Resuming an episode does work from the Recently Played menu though. All actions on the SB Radio b.t.w.

Seems a bit strange to me that this behaviour is caused by the number of items in the feed, but I haven't looked at the code yet. So it might be logical.

Does it work properly if you back out of the Mac Power User podcast list and then re-enter it?

Sent from my Pixel 3a using Tapatalk

[mrw]

Seems a bit strange to me that this behaviour is caused by the number of items in the feed, but I haven't looked at the code yet. So it might be logical.

Well, I’ve already shown you a cause of the problem. As an easier fix, try fixing the plug-in to limit the number of items returned to 200, or perhaps 199.