Restart VLC instance after a crash

[Shaunie1975]

Hello experts,

I am running VLC 2.0.2 Twoflower
I have a little batch file that runs 12 instances of VLC and places them around my screen. I tried using a newer version of VLC but it would seem to work with my batch file.

They are all monitoring local UDP streams. Every now and then one or two of them seems to crash.
Is it possible to have VLC restart these particular instances if they crash?

If anyone is interested this is similar to the batch file I am using:

Code: Select all

REM - Top Row cd C:\Program Files (x86)\VideoLAN\VLC start vlc C:\vlc\3X2\Stream-1.xspf --video-title-timeout=2147483647 --no-video-deco --no-embedded-video --video-x=1 --video-y=1 --width=640 --video-on-top --aspect-ratio=16:9 TIMEOUT /T 1 /NOBREAK cd C:\Program Files (x86)\VideoLAN\VLC start vlc C:\vlc\3X2\Stream-2.xspf --video-title-timeout=2147483647 --no-video-deco --no-embedded-video --video-x=640 --video-y=1 --width=640 --video-on-top --aspect-ratio=16:9 TIMEOUT /T 1 /NOBREAK cd C:\Program Files (x86)\VideoLAN\VLC start vlc C:\vlc\3X2\Stream-3.xspf --video-title-timeout=2147483647 --no-video-deco --no-embedded-video --video-x=1280 --video-y=1 --width=640 --video-on-top --aspect-ratio=16:9 TIMEOUT /T 1 /NOBREAK #REM - Bottom Row cd C:\Program Files (x86)\VideoLAN\VLC start vlc C:\vlc\3X2\Stream-4.xspf --video-title-timeout=2147483647 --no-video-deco --no-embedded-video --video-x=1 --video-y=360 --width=640 --video-on-top --aspect-ratio=16:9 TIMEOUT /T 1 /NOBREAK cd c:\Program Files (x86)\VideoLAN\VLC\ start vlc C:\vlc\3X2\Stream-5.xspf --video-title-timeout=2147483647 --no-video-deco --no-embedded-video --video-x=640 --video-y=360 --width=640 --video-on-top --aspect-ratio=16:9 TIMEOUT /T 1 /NOBREAK cd \Program Files (x86)\VideoLAN\VLC\ start vlc C:\vlc\3X2\Stream-6.xspf --video-title-timeout=2147483647 --no-video-deco --no-embedded-video --video-x=1280 --video-y=360 --width=640 --video-on-top --aspect-ratio=16:9 TIMEOUT /T 1 /NOBREAK

[Hitchhiker]

You'd be advised to update to the latest version which is 3.0.4 since any version less than 2.2.8 is insecure. Vulnerabilities include the following:

1. Use-After-Free Memory Error in Processing MKV Files
2. File Processing Type Conversion Error in 'modules/demux/mp4/libmp4.c

For assistance with your problem please follow instructions in the orange box.

To help you, we need messages, to completely understand what your problems is.
To fix this, please be sure before you start the playback to:

1. Open: Tools -> Messages.
2. Set Verbosity to 2
3. Start playback to reproduce your issue
4. Save text in a file or copy into clipboard
5. Then paste the full resulting log here between [​code]and[​/code] (or use Pastebin.com if it's too long)

Also don't forget to name your Operating System and provide the VLC media player version.

[Moriquendi]

Hi Shaunie,

Is there a specific reason you are using VLC 2.0.2? If not, as Hitchhiker suggested, I'd also recommend using VLC 3.0.4 as it is a lot more stable and resilient to the crashes.

[unidan]

Hi Shaunie,

Is there a specific reason you are using VLC 2.0.2? If not, as Hitchhiker suggested, I'd also recommend using VLC 3.0.4 as it is a lot more stable and resilient to the crashes.

And has not web-documented security flaws.

[Shaunie1975]

Hello,

I am using 2.0.2 as new versions do not allow me to resize screens with the --width command.

I have tried nightly build as I read that these commands will be coming back in. Indeed a nightly build did allow the --width command but also brought some other issues (high CPU usage) so I reverted back to 2.0.2

I'm not too worried about security flaws as its a standalone machine with no internet access.

In a nut shell:
Its monitoring local streams (I receive a several sat signals, from up to 3 different satellites on a Triax receiver) that the spits them out as RTP streams which is streamed around my office building.

I use VLC to monitor these streams so that if any drop I can check if the satellite has moved off target (stabilised antennas)

I'll look at getting some debug messages from it too.

Thanks

[Jean-Baptiste Kempf]

I have tried nightly build as I read that these commands will be coming back in. Indeed a nightly build did allow the --width command but also brought some other issues (high CPU usage) so I reverted back to 2.0.2

High CPU while playing UDP or in all playback?

[Moriquendi]

Hi JB,

I also have an application with 4 embeded VLC players. I used to have VLC 2.2.8 but due to some crashes and bugs, I updated libvlc api to 3.0.4. But now I have high cpu usage problems and yes I am playing 1080p TS UDP streams. Is that a bug or there is a workaround?

Regards.

[Shaunie1975]

I have tried nightly build as I read that these commands will be coming back in. Indeed a nightly build did allow the --width command but also brought some other issues (high CPU usage) so I reverted back to 2.0.2

High CPU while playing UDP or in all playback?

I only use the machine for playback of UDP streams.

[Shaunie1975]

You'd be advised to update to the latest version which is 3.0.4 since any version less than 2.2.8 is insecure. Vulnerabilities include the following:

1. Use-After-Free Memory Error in Processing MKV Files
2. File Processing Type Conversion Error in 'modules/demux/mp4/libmp4.c

For assistance with your problem please follow instructions in the orange box.

To help you, we need messages, to completely understand what your problems is.
To fix this, please be sure before you start the playback to:

1. Open: Tools -> Messages.
2. Set Verbosity to 2
3. Start playback to reproduce your issue
4. Save text in a file or copy into clipboard
5. Then paste the full resulting log here between [​code]and[​/code] (or use Pastebin.com if it's too long)

Also don't forget to name your Operating System and provide the VLC media player version.

Hello Hitchiker,

I have a log file now but is too large to paste here and also too large for Pastebin (exceeds 512kb)
I'll look for somewhere to host the file and post back soon.

The last 50 or so lines are below. and to be honest the other 90+k lines are pretty much the same a:

ts warning: invalid header [0x7d:79:c7:a9] (pid: 204)
ts warning: discontinuity received 0xf instead of 0xe (pid=304)

Code: Select all

ts debug: transport_error_indicator set (pid=204) ts warning: discontinuity received 0x3 instead of 0x2 (pid=204) ts debug: transport_error_indicator set (pid=204) ts debug: transport_error_indicator set (pid=204) ts debug: transport_error_indicator set (pid=204) ts debug: transport_error_indicator set (pid=204) ts warning: invalid header [0x7d:79:c7:a9] (pid: 204) ts warning: discontinuity received 0xf instead of 0xe (pid=304) main debug: incoming request - stopping current input main debug: dying input main debug: control: stopping input main debug: dying input ts debug: eof ? main warning: can't get output picture main debug: removing module "avcodec" avcodec debug: ffmpeg codec (H264 - MPEG-4 AVC (part 10)) stopped main debug: killing decoder fourcc `h264', 1 PES in FIFO main debug: saving a free vout main debug: reusing provided vout main debug: removing module "packetizer_h264" main debug: removing module "rtp" rtp debug: removing RTP source (8765005c) main debug: removing module "ts" ts debug: pid list: ts debug: - pid[0] seen ts debug: - pid[1] seen ts debug: - pid[17] seen ts debug: - pid[20] seen ts debug: - pid[104] seen ts debug: - pid[192] seen ts debug: - pid[204] seen ts debug: - pid[304] seen main debug: Program doesn't contain anymore ES ts debug: - pid[404] seen ts debug: - pid[3588] seen ts debug: - pid[3589] seen ts debug: - pid[8191] seen main debug: dead input main debug: destroying useless vout main debug: removing module "direct3d" direct3d debug: Direct3D scene released successfully direct3d debug: DirectXEventThread terminating direct3d debug: DirectXCloseWindow direct3d debug: WinProc WM_DESTROY main debug: Filter 26e50710 removed from chain main debug: removing module "deinterlace" main debug: removing module "freetype" main debug: removing module "yuvp" main debug: removing module "swscale" qt4 debug: IM: Deleting the input main debug: TIMER input launching for 'rtp://239.72.2.41:5000' : 3.055 ms - Total 3.055 ms / 1 intvls (Avg 3.055 ms)

[staticfl]

I have a similar issue with most versions of 3.0.x crashing while playing a multicast stream internal to our network. Some previous versions of 2.2.x work fine, specifically 2.2.8 works perfectly. It connects to the stream and instantly crashes to desktop. It's streaming from a Over The Air blunder tongue streaming server with zero issues from that since it works on other vlc versions. Here's the log. Any suggestions?

https://pastebin.com/98Wm3EWX