Project

General

Profile

Bug #593

Scanning HTTP playlist entries delays playback of local files

Added by Evgen Whatever about 9 years ago. Updated about 9 years ago.

Status:
Closed
Priority:
Minor
Assignee:
-
Category:
libaudcore
Target version:
3.7.1
Start date:
November 21, 2015
Due date:
% Done:

100%

Estimated time:
Affects version:
3.7

Description

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.

History

#1 Updated by John Lindgren about 9 years ago

Could you list a minimal set of steps, starting from a default configuration, to reproduce the problem?

#2 Updated by Evgen Whatever about 9 years ago

Problem appears when you have few (at least 2) "broken" streams in playlist.
1) Add to playlists at least 2 unavailable streams. For example
  • http://live.galaradio.com:8000/kiev
  • http://live.galaradio.com:8000/kraina
    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 about 9 years 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.

#4 Updated by John Lindgren about 9 years ago

  • Category changed from core to libaudcore

#5 Updated by John Lindgren about 9 years ago

  • Status changed from New to Closed
  • Target version set to 3.7.1
  • % Done changed from 0 to 100

Also available in: Atom PDF