Scanning HTTP playlist entries delays playback of local files
|Status:||Closed||Start date:||November 21, 2015|
For some reasons if you previously loaded some radio-stream, then restarted player and trying to load some local track (e.g. mp3), playback won't start immediately. Instead there will be "buffering" and only after that playback starts. Next local track will play normally. With next restarts problem will be still there (and it doesn't matter if you previously listened to mp3 or radio). Actually "paused" tracks from previous session will continue fine but if you try to load different track - "buffering". It will continue until you disable Neon plugin or remove all "stream items" from playlist from where one of them was originally loaded.
Current workaround is an option "Don't load metadata for songs until played". Still on terminal I see that "Neon plugin" scans "https" (I have some that currently doesn't work). And also if you decide to exit right after starting player, process won't unload until scan is finished.
#1 Updated by John Lindgren 11 months ago
Could you list a minimal set of steps, starting from a default configuration, to reproduce the problem?
#2 Updated by Evgen Whatever 11 months ago
1) Add to playlists at least 2 unavailable streams. For example
2) Add some track (e.g. mp3)
3) Restart player and try to load (not resume) that mp3.
You should get delay (~8 seconds) with "buffering..." in the title bar.
Also if you open player and try to close it immediately, you'll get hang (~11 seconds) before closing. In this case desktop environment (XFCE) after 5-th second will think that "Audacious" doesn't respond and ask if you want to terminate this program.
#3 Updated by John Lindgren 11 months ago
- Subject changed from Neon plugin activates itself and delays playback of non-radio to Scanning HTTP playlist entries delays playback of local files
- Category changed from plugins/neon to core
- Priority changed from Major to Minor
Okay, I think I understand what is going on. There is a "pool" of two metadata-scanning threads, and if both of those are busy when you start playback, it will wait until one becomes free. I will see if there's a way to do the metadata scanning from the playback thread itself and avoid the delay that way.