Mpv: Crashes when changing channel (DVB)

[yaomtc]

Important Information

Provide following Information:

• mpv version 0.32.0
• Arch Linux (latest)
• Source of the mpv binary: community repository
• Window Manager: Xorg 1.20.8-1
• GPU driver: Mesa 20.0.4

Reproduction steps

1. Add these lines to input.conf:

H cycle dvbin-channel-switch-offset up
K cycle dvbin-channel-switch-offset down

1. Have a DVB card installed and a valid channels.conf in place, and run mpv dvb://
2. Once TV starts playing, hold shift and press H or K.
3. dvbin-channel-switch-offset up or down should appear in the OSD, before it crashes.

My channels.conf (which works with mplayer, and works with any specified channel in mpv) is in ~/.config/mpv as well.

Expected behavior

Channel should switch without mpv crashing.

Actual behavior

mpv crashes.

Log file

mpv-channel-switch-crash.txt

[ghost]

Can you make a log with --msg-level=dvbin=trace?

[ghost]

I stared at the code some, but I can't find any problem. I found some unrelated benign issue (and pushed a fix to master for it), which should not affect this in a good or bad way.

The crash looks like an internal logic error, unless the DVB code somehow misbehaves or stomps over memory. Maybe @olifre can try to reproduce it. If anyone has a .ts fragment that causes the crash (and confirms the theory that it's just a stream.c internal logic error unrelated to DVB) I can fix it.

[olifre]

I gave it a try just now and could not reproduce it with a DVB-S/S2 card (large mpeg2 and h264 streams), but with a DVB-T card (less bitrate, mpeg2) I can reproduce it every 5 channel switches or so.

I think it's a logic error in the DVB code indeed — it seems to vanish once I drop this:
https://github.com/mpv-player/mpv/blob/c2ee7bce4cab472f1378b4b2a9e69c5f18223f3c/stream/stream_dvb.c#L839
This is called (indirectly) within the stream->fill_buffer call, i.e. in dvb_streaming_read, which checks if the config has updated (different channel offset) and then initiates the switch. It's probably not a good idea to drop the buffers in fill_buffers.

I think there is no other place we can call it, though, since we have to handle the change of the channel within fill_buffer. However, it seems we can just drop that line, at least I don't notice any slowdown of the channel switching due to this with the streams I have available.

@wm4 Could this explain the observed error?

[ghost]

If that is called from fill_buffer, then definitely.

[olifre]

@wm4 Perfect :-). The call was very well hidden (through three different functions) which is why I missed that before. The linked PR fixes it, once tests are green and I get an OK from you, I'll merge it.

[yaomtc]

Holy crap, you guys are quick. Thank you! I'll compile this and give it a try shortly.

[yaomtc]

Having enabled dvbin in the PKGBUILD for the mpv-git AUR package, I tried running mpv dvb:// again, but unlike in the Arch package I don't get any output as it fails to open dvb://, and fails to lock in to a signal:

https://gist.github.com/yaomtc/4d4bffcd892c5e17a4dc61f792c13965

Should I file a separate bug for this? Could it just be a dependency/feature I'm missing for compile?

EDIT2: misread the first comment, here is my output with --msg-level=dvbin=trace

https://gist.github.com/yaomtc/782219a7635c45a884ea5f89f4454516

[olifre]

@yaomtc The log output is exactly the same as the previous working one up to the tuning, and the exact same commands are sent to the card via ioctl to tune — the only difference is that the card does not lock to a signal. Since there have been no changes related to DVB tuning between 0.32.0 and master, I am really at a loss what is happening here, we essentially send the same commands to the kernel but it does not report back that the card has locked.

Can you confirm that it still tunes fine with mpv 0.32.0 or w_scan?
Is the kernel log showing anything?
Does powercycling the adapter change things?

[yaomtc]

Hmm, this might be something wrong on my end as the issue is now occurring with mpv 0.32.0 as well... I'll see if re-seating the card and rebooting does anything.

[yaomtc]

Yeah, it's a hardware issue. The card seems finnicky about the slot, probably kinda worn out given how old the card is. Just tested channel changing and it works for me too.

Thanks again!

[olifre]

Thanks for testing and reporting back (not everybody does it) :+1: .

I can also feel your pain about dying old cards — shortly after the dark ages when things were still analog and there was no mpv, I've switched to USB cards for digital TV, after I had a single DVB PCI card which had no Linux drivers.
For my first USB device, the manufacturer never implemented a kernel driver with DVB-S2 (and no manufacturer docs were available) so it was limited to DVB-S, the next one suddently created erroneous stream data after warranty was over.

My currently working cards are slowly approaching >5 years of age (keeping my fingers crossed). Technically, your issue could also be caused by a kernel driver bug (my card's driver was indirectly affected by similar issues after a core kernel change two years ago), but usually the results are "consistently broken" when it's a driver bug, so I'm afraid you are right and the hardware is dead :-(.
Of course, if the issues came also together with a newer kernel, you may want to try if it works more stable with an older kernel (if you can easily do so), just to make sure.

Thanks for testing in any case!

[yaomtc]

Back in like 2008, my capture card was an analog Hauppauge card, and I used tvtime. It worked so smoothly and was so simple! It's too bad there seems to be nothing like it currently that works with ATSC. MPV is close enough, though.