Opened 7 years ago

Last modified 23 months ago

#2945 evaluated Bug

MPC-HC hangs on loading an *.m3u file with more than one http:// url inside

Reported by: Drugoy_ Owned by:
Priority: high Milestone:
Component: General Version:
Severity: major Keywords:
Cc: Evaluation: need info

Description

I have an *.m3u playlist that contains links to streaming video channels.
VLC plays it fine, but MPC-HC hangs upon loading it.
However, if a playlist file contains only one single link - MPC-HC plays it fine.

Change History (20)

comment:1 Changed 7 years ago by Robert Schlabbach

Maybe you could provide a sample playlist? I tried putting http://www.google.com, http://www.bing.com and http://www.yahoo.com in an m3u file and MPC-HC did NOT hang on loading it...

Last edited 7 years ago by Robert Schlabbach (previous) (diff)

comment:2 Changed 7 years ago by Drugoy_

Does Google or Bing or Yahoo stream video?
my playlist contains urls to local resources, so you won't be able to reach them:
http://10.204.5.3:5555/udp/224.0.90.183:1234
http://10.204.5.3:5555/udp/224.0.90.83:1234

comment:3 Changed 7 years ago by Underground78

Cc: Underground78 added
Component: NewNeed Info
Milestone: next release

Do you think you could find a way to reproduce that with URLs we can reach?

comment:4 Changed 7 years ago by Drugoy_

sadly, I don't think so. All the publicly available video streams I could find were using rtmp:// protocol (example is: rtmp://live.yycast.com:1935/lb/ ) and mpc-hc simply doesn't handle it :(

comment:5 Changed 7 years ago by Underground78

How do you stream those resources? Could I setup the same thing?

comment:6 Changed 7 years ago by Robert Schlabbach

You can actually repro the behavior without having a server - just use the two private URLs @Drugoy_ posted. MPC won't hang indefinitely, just take a long time to start, during which it is completely unresponsive.

The behavior is not actually linked to HTTP streams. I observed the same behavior when using M3U files with a long list of video files to play. I assume that upon opening, MPC scans through all the files (or HTTP links in this case), and depending on the number of items - or the (in)availability of the streams in the file - the process takes a long time, during which MPC won't respond to any input.

Possibilities I see for a fix:

  1. Offload the M3U list scanning into a thread separate from the GUI thread so that MPC can be controlled or closed while it is running. Some progress indicator would also be nice.
  1. Look into the possibility of omitting the M3U list scanning. Is it really necessary to scan through the M3U list at startup, or can looking at the items therein be deferred to the point at which an item is actually to be played?

comment:7 Changed 7 years ago by Drugoy_

Finally I've found a publicly available http streaming video, but it's HLS: http://iphone.1internet.tv/iphone/stream.m3u8

comment:8 Changed 6 years ago by Underground78

Can you try the latest nightly build and report back?

comment:9 Changed 6 years ago by Drugoy_

Still the same: if the m3u file contains only 1 link to the 1 stream - mpc-hc plays it well, but if the m3u playlist contains more links - mpc-hc hangs (totally unresponsive) forever.

comment:10 Changed 6 years ago by Drugoy_

IIRC - earlier I had problems with even 2 http:// links in 1 .m3u file - opening such a playlist always resulted in mpc-hc hanging forever.

Maybe because of mpc-hc now supports HLS or for some other reason - it now works.

I've ran 3 tests of opening a playlist with numerous links to http:// streaming videos inside:
2 links - a very short startup hang
20 links - ~1 minute startup hang
95 links - ~5 minutes startup hang

The startup hang makes mpc-hc's GUI totally unresponsive (even the close button doesn't work), as well it may affect explorer's short hangs/visual lags.

comment:11 Changed 6 years ago by Drugoy_

I've just opened Playlist (Ctrl+7) and it appears that lines like

#EXTINF:-1 tvg-name="Первый Канал" group-title="Эфирные", Первый Канал
#EXTVLCOPT:deinterlace=-1
#EXTVLCOPT:deinterlace-mode=yadif2x
#EXTVLCOPT:udp-caching=2000
are all treated as video-sources (hence, all are marked as "Invalid").

However, removing those lines doesn't speed up opening the playlist much.

I don't know anything about *.m3u format's standards of the internal data, but that playlist seems to be working way better with VLC, so if that format is valid - shall I open a new ticket about bringing support of those kinds of internal data?

comment:12 Changed 6 years ago by Underground78

I need to completely rewrite the playlist handling basically because it's quite bad currently.

comment:13 Changed 6 years ago by Drugoy_

Saved the very same playlist in *.mpcpl - and there's no startup lag at all.

comment:14 Changed 4 years ago by kwskkwsk

Is there any progress in this bug?
It still no response to play m3u version 1.7.10

comment:15 in reply to:  14 Changed 4 years ago by Drugoy_

No, still no progress.

comment:16 in reply to:  description Changed 3 years ago by narspt

I can experience same problem, apparently the reason is that mpc-hc wants to connect to ALL remote streams in the playlist when loading it, to get extra infos for each one I guess... like it does for local files... but for streams this makes no sense and just hangs the program for long time (depending on the playlist size). Hope some developer can fix this.

Last edited 3 years ago by narspt (previous) (diff)

comment:17 in reply to:  12 Changed 2 years ago by acDCuk

Replying to Underground78:

I need to completely rewrite the playlist handling basically because it's quite bad currently.

+1

comment:18 Changed 2 years ago by clsid2

Cc: Underground78 removed
Version: 1.6.5.6366

comment:19 Changed 23 months ago by Chatty

Also links from livespotting aren't working with latest nightly (1.7.13.112):

http://stream.livespotting.tv/windit-edge/vv131_720p.stream/playlist.m3u8

comment:20 Changed 23 months ago by clsid2

Video works for that livespotting stream with latest version of LAV Filters.

Note: See TracTickets for help on using tickets.