| Summary: | Podcast position is lost if paused for too long | ||
|---|---|---|---|
| Product: | [Applications] kasts | Reporter: | Nicolás <nicoadamo> |
| Component: | general | Assignee: | bart |
| Status: | REPORTED --- | ||
| Severity: | normal | CC: | nicoadamo |
| Priority: | NOR | ||
| Version First Reported In: | 24.12.1 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: | Before reproducing the bug, when paused. I couldn't reproduce it now after the resume / play button was pressed. | ||
|
Description
Nicolás
2025-01-25 20:20:18 UTC
This is a very vague description, and not something I've ever seen happen in the wild. The code of the app only allows a limited amount of situations for a podcast episode to be marked read. I assume that there is something very particular going on with the audio backend or the particular podcast in question. Could you please provide some extra information about the conditions so I can reproduce the issue? E.g. which audio backend, which podcast/episode, what happened while it was paused? Perhaps do a screen capture of it happening? If it's not reproducible, we can't fix it. Oooh sure. It's using the stream option, not the Download option. The audio backend is "VLC player". I tried the other one (Qt Mutimedia) but under Arch Linux with plasma, it automatically always returns to VLC player. The podcast is https://anchor.fm/s/eb22fd30/podcast/play/97325475/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2025-0-20%2F393416934-44100-2-620c015273d95.mp3 I tried to replicate it now, after nearly an hour paused, and the bug didn't reproduce. I meant to take "before and after" snapshots, but I could only take the "before". I'll upload it anyway. Another piece of information: When starting a streaming from scratch under Kasts, or if closed and then opened again, it usually copies whatever audio setting was left in the VLC player application itself (expected or not, that's what I see). The other audio application that I alternate Kasts with is Strawberry player. Created attachment 177679 [details]
Before reproducing the bug, when paused. I couldn't reproduce it now after the resume / play button was pressed.
Thanks for the input. The mention that you're streaming really helps narrowing it down. I can see how pausing a stream for a long time could make the connection time out. If VLC then throws an invalid media error, Kasts would consider that as the episode not being available for playing. Under certain circumstances the episode could then be marked as played (because Kasts thinks that it doesn't exist). If this is the real scenario, then the bug would depend on the behaviour of the remote server, and how your local host manages outgoing connections (e.g. time outs for those). I'll have to think how to handle this... The issue is that Kasts would have to work around the audio backend (VLC) not being able to keep the connection open for an indefinite amount of time. NB: Please realize that streaming audio is quite brittle. Especially when you're talking to a bunch of servers that are not under your or the app's direct control. NB2: You can avoid this problem by clicking on the play button on the episode itself when you return after a while. (So not the play button in the audio controls bar at the top, but really the button on the right hand side of the list item.) This button will completely reload the audio from scratch, avoiding any kind of time-out errors. Brilliant! All what you described as the possible scenario makes total sense! Thanks a lot for the workaround! |