Created attachment 176593 [details] screenshot showing Kasts queue page with the issue SUMMARY As shown in the attached screenshot, Kasts is showing zero-length for an audio file that is almost 3 hours long, but it happens with shorter files as well. VLC audio engine is set. It seems to be podcast-specific (all the episodes of this podcast are affected), then it's maybe something related to the specific codec used by AmpHour folks and VLC not being happy with it? Any chance that Kasts can anyway show the right length? When you'd like to check yourself, RSS feed is at [1]. The file itself is recognized correctly by ffmpeg marco@mobian:~/.local/share/KDE/kasts/enclosures/The Amp Hour Electronics Podcast$ ffmpeg -i 684\ Lee\ Felsenstein\ The\ Computer\ Revolution\ Counterculture.1e9d2a.mp3 ffmpeg version 7.1-3 Copyright (c) 2000-2024 the FFmpeg developers built with gcc 14 (Debian 14.2.0-7) configuration: --prefix=/usr --extra-version=3 --toolchain=hardened --libdir=/usr/lib/aarch64-linux-gnu --incdir=/usr/include/aarch64-linux-gnu --arch=arm64 --enable-gpl --disable-stripping --disable-libmfx --disable-omx --enable-gnutls --enable-libaom --enable-libass --enable-libbs2b --enable-libcdio --enable-libcodec2 --enable-libdav1d --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libglslang --enable-libgme --enable-libgsm --enable-libharfbuzz --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzimg --enable-openal --enable-opencl --enable-opengl --disable-sndio --disable-libvpl --enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-chromaprint --enable-frei0r --enable-ladspa --enable-libbluray --enable-libcaca --enable-libdvdnav --enable-libdvdread --enable-libjack --enable-libpulse --enable-librabbitmq --enable-librist --enable-libsrt --enable-libssh --enable-libsvtav1 --enable-libx264 --enable-libzmq --enable-libzvbi --enable-lv2 --enable-sdl2 --enable-libplacebo --enable-librav1e --enable-pocketsphinx --enable-librsvg --enable-libjxl --enable-shared libavutil 59. 39.100 / 59. 39.100 libavcodec 61. 19.100 / 61. 19.100 libavformat 61. 7.100 / 61. 7.100 libavdevice 61. 3.100 / 61. 3.100 libavfilter 10. 4.100 / 10. 4.100 libswscale 8. 3.100 / 8. 3.100 libswresample 5. 3.100 / 5. 3.100 libpostproc 58. 3.100 / 58. 3.100 Input #0, mp3, from '684 Lee Felsenstein The Computer Revolution Counterculture.1e9d2a.mp3': Metadata: title : The Amp Hour 684 - Lee Felsenstein album : The Amp Hour track : 684 genre : Podcast publisher : The Amp Hour encoded_by : David Jones album_artist : The Amp Hour artist : Lee Felsenstein date : 2024 Duration: 02:58:06.62, start: 0.023021, bitrate: 256 kb/s Stream #0:0: Audio: mp3 (mp3float), 48000 Hz, stereo, fltp, 256 kb/s Metadata: encoder : LAME3.100 At least one output file must be specified [1] https://theamphour.com/feed/podcast/ OBSERVED RESULT 0:00:00 is shown as episode's length EXPECTED RESULT real length of the audio file to be shown SOFTWARE/OS VERSIONS Linux: 6.6-qcom (Mobian testing) KDE Plasma Version: 6.2.4 KDE Frameworks Version: 6.8.0 Qt Version: 6.7.2
A possibly relevant merge request was started @ https://invent.kde.org/multimedia/kasts/-/merge_requests/206
The issue here is that the duration of the enclosure is supposed to be set correctly in the rss feed entry itself. So the ultimate solution is to get the author to set the duration correctly in the feed in the first place. If the author hasn't done that, there is no way of knowing the length of the episode until you have actually retrieved the file. However, we can of course update the duration once an episode has been downloaded. The current version of Kasts does that when you start playing the file. I've just opened an MR to already probe for the duration as soon as the file has been downloaded, which would already help a lot. Unfortunately, it seems that a lot of people are directly streaming episodes rather than downloading them first. For those situations, there is no solution: the wrong duration will be shown until they start playing the file. (I don't want to start probing/streaming every entry in a list just to get the duration. You would probably get banned for DoSing the service.)
Git commit e77f317f911ddad40f9592994ba66150aaaccac9 by Bart De Vries. Committed on 15/12/2024 at 18:51. Pushed by bdevries into branch 'master'. Retrieve duration from file as soon as it's downloaded This will replace the less reliable duration as retrieved from the rss feed entry. M +11 -1 src/enclosure.cpp https://invent.kde.org/multimedia/kasts/-/commit/e77f317f911ddad40f9592994ba66150aaaccac9
Created attachment 176663 [details] screenshot with Kasts patched with relevant MR Hi, sorry it took me so long to build the patched Kasts to check the fix: yes, the actual length of the episode is now shown (thank you!), but the value of the remaining time to be played isn't updated until the app is restarted. It would make sense that a recalculation of the remaining play time is triggered when an episode is downloaded. But we're now down in the details' realm, it's not a big issue anyway...
I'm pretty sure that the remaining time will also get immediately updated as soon as you start playing *any* episode. Anytime any play position changes, that remaining time gets updated. That should happen about every second when playing. I think that should be sufficient? Could you perhaps check that my statement is indeed correct at your end?
Git commit e67b9ed3bbbfc52b5c835981cebbf4a2635d4d41 by Bart De Vries. Committed on 15/12/2024 at 20:22. Pushed by bdevries into branch 'release/24.12'. Retrieve duration from file as soon as it's downloaded This will replace the less reliable duration as retrieved from the rss feed entry. M +11 -1 src/enclosure.cpp https://invent.kde.org/multimedia/kasts/-/commit/e67b9ed3bbbfc52b5c835981cebbf4a2635d4d41
(In reply to bart from comment #5) > I'm pretty sure that the remaining time will also get immediately updated as > soon as you start playing *any* episode. Anytime any play position changes, > that remaining time gets updated. That should happen about every second > when playing. I think that should be sufficient? > > Could you perhaps check that my statement is indeed correct at your end? AmpHour is the only podcast with this issue, then I should wait for their next episode to be available. But I trust your experience, so I will call this fixed! ;)