Bug#1026060: Bug: #1026060 -- mpv: dvb playback does not work anymore
Hi Alf, Alf writes: > On Sun, 23 Apr 2023 12:49:19 +0200 Alf wrote: > Further investigating the configuration also led to a solution for the higher > CPU load: > > SMPlayer seems not to evaluate my $HOME/.config/mpv/mpv.conf where I have > hardware accelleration enabled. > I now have set it additionally in SMPlayers configuration under [snip] > > Sorry for using this bug report to describe configuration hints for SMPlayer, > but such informnation is hardly available in the web. Thank you for confirming there wasn't a regression, as well as that it was a config issue, and congrats on finding a fix! Yes, I agree that it's better to share hints like these rather than sit on them; however, I worry that many people won't be able to find this info once this bug is archived. Would you please consider adding your findings to the following article: https://wiki.debian.org/HardwareVideoAcceleration It's an opportunity for us to do better than the Arch wiki ;) I don't remember if there's an application process for editor permissions these days, but if there is feel free to link to this bug and mention me. Cheers, Nicholas signature.asc Description: PGP signature
Bug#1026060: mpv: dvb playback does not work anymore
James Addison writes: > On Sun, 23 Apr 2023 at 00:28, Nicholas D Steeves wrote: >> The way always screen for this type of thing is using the >> "elpa-git-timemachine" Emacs package > > That sounds like a nice feature integration. I worry that I might be > too many years into my vim usage to change course and learn emacs > effectively.. but I'll consider it :) > Oh, vim. Hmm. In that case, the following seems to provide equivalent functionality (I haven't tried it): http://vimcasts.org/episodes/fugitive-vim-exploring-the-history-of-a-git-repository/ >> 'just saying, this was something you could have fixed, had you >> needed/wanted to ;) > > In hindsight: yes, I think I probably should have attempted a fix > alongside the report. I've been trying not to jump onto bugthreads > too quickly before having findings to share - as the release freeze > continues though, I may have been starting to (over)react more > quickly. That's understandable, because Debian stable could end up having to live with these bugs for two years. As you know, there's also the freeze policy, and associated risk/benefit analysis. https://release.debian.org/bullseye/freeze_policy.html > So: next time! Brilliant! My availability is spotty, but feel free to CC me for review, sponsorship, and related questions (ie: is this changes a candidate for an unblock?) Thank you for confirming mpv 0.35.1-4 didn't introduce a new regression. > However: I do have problems playing an MP4 video file with the > 'default' video output driver selected. Maybe that is the same issue > with VAAPI.. or maybe something else. I'll spend some time to check, > I think that either/both of those should be reported/followed in > separate bug(s). Yup, you're right. There may also be documentation-related issues related to VAAPI (ie there is now i965-va-driver, intel-media-va-driver, and intel-media-va-driver-non-free), or maybe "default" is for mplayer and not mpv. 'not sure if that's an autodetection bug or a documentation bug. Take care, Nicholas signature.asc Description: PGP signature
Bug#1026060: Bug: #1026060 -- mpv: dvb playback does not work anymore
On Sun, 23 Apr 2023 12:49:19 +0200 Alf wrote: Hi Nicholas But that's also not true - it now works as before after switching the settings under "General" -> "Video" -> "Output driver" from "vaapi" to "libmpv" - that's all! I only use smplayer because of the comfortable way to zap between different channels. So with using "libmpv" I have definitely higher CPU-load (~12%) compared to mpv using vaapi (~1-2%)., but that's no issue for me. First of all many thanks for the hint to look for SMPlayer settings which led to get it working by changing "Output driver". Further investigating the configuration also led to a solution for the higher CPU load: SMPlayer seems not to evaluate my $HOME/.config/mpv/mpv.conf where I have hardware accelleration enabled. I now have set it additionally in SMPlayers configuration under Setting-> Advanced -> Mplayer/mpv -> Options --hwdec=vaapi (Attention: different to mpv.conf the option needs to be prefixed with 2 dashes) This way CPU load in SMPlayer drops down to only 1-2% - precisely as in MPV native. Also logs of smplayer are similar to mpv native: AO: [pipewire] 48000Hz stereo 2ch floatp VO: [gpu] 1280x720 vaapi[nv12] INFO_VIDEO_DSIZE=1280x720 MPV_VERSION=mpv 0.35.1 You can monitor GPU usage with the tool "intel-gpu-top" from the Debian-repo. Watch the ENGINE "Video". Any output !0 indicates hardware decoding. Also my first setting for "Video" -> "Output driver" may be changed back to "Default". That gives the same result, also other selections work, i.e. "gpu" but not all enable HW-decoding. Just "vaapi" throws errors. Sorry for using this bug report to describe configuration hints for SMPlayer, but such informnation is hardly available in the web. Thanks, Alf
Bug#1026060: mpv: dvb playback does not work anymore
On Mon, 24 Apr 2023 at 14:05, James Addison wrote: > > However: I do have problems playing an MP4 video file with the > 'default' video output driver selected. Maybe that is the same issue > with VAAPI.. or maybe something else. I'll spend some time to check, > I think that either/both of those should be reported/followed in > separate bug(s). I should have been clearer when writing that paragraph: The problems that I've encountered with smplayer when attempting to play an MP4 file occur for both mpv version 0.35.1-3 and also version 0.35.1-4 -- that is to say: they are not a regression related to this bug.
Bug#1026060: mpv: dvb playback does not work anymore
On Sun, 23 Apr 2023 at 00:28, Nicholas D Steeves wrote: > > You're welcome! Also, yes, your hypothesis about DVB support being lost > when the Debian packages adapted to upstream's waf-to-meson change was > correct. The way always screen for this type of thing is using the > "elpa-git-timemachine" Emacs package. You checkout a repository, open > debian/rules, "M-x git-timemachine", and then using the "p" key to step > back through the history of the file, and then use "f" to step forward > to flip back. There are other ways to achieve this results, of course. That sounds like a nice feature integration. I worry that I might be too many years into my vim usage to change course and learn emacs effectively.. but I'll consider it :) > 'just saying, this was something you could have fixed, had you > needed/wanted to ;) In hindsight: yes, I think I probably should have attempted a fix alongside the report. I've been trying not to jump onto bugthreads too quickly before having findings to share - as the release freeze continues though, I may have been starting to (over)react more quickly. So: next time! > If you have a moment, could you confirm that it didn't break smplayer > for you? The release team will want confirmation on way or the other. When using smplayer with both mpv 0.35.1-3 and also mpv 0.35.1-4 installed - and with 'libmpv' configured as the video output driver (thanks, Alf!) - I can play video (a sample MP4 file) correctly. However: I do have problems playing an MP4 video file with the 'default' video output driver selected. Maybe that is the same issue with VAAPI.. or maybe something else. I'll spend some time to check, I think that either/both of those should be reported/followed in separate bug(s). Thanks, James
Bug#1026060: Bug: #1026060 -- mpv: dvb playback does not work anymore
Here for completeness (just in case you want to dig into smplayer's vaapi issue): $ vainfo libva info: VA-API version 1.17.0 libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so libva info: Found init function __vaDriverInit_1_17 libva info: va_openDriver() returns 0 vainfo: VA-API version: 1.17 (libva 2.12.0) vainfo: Driver version: Intel iHD driver for Intel(R) Gen Graphics - 23.1.1 () vainfo: Supported profile and entrypoints VAProfileNone : VAEntrypointVideoProc VAProfileNone : VAEntrypointStats VAProfileMPEG2Simple: VAEntrypointVLD VAProfileMPEG2Simple: VAEntrypointEncSlice VAProfileMPEG2Main : VAEntrypointVLD VAProfileMPEG2Main : VAEntrypointEncSlice VAProfileH264Main : VAEntrypointVLD VAProfileH264Main : VAEntrypointEncSlice VAProfileH264Main : VAEntrypointFEI VAProfileH264Main : VAEntrypointEncSliceLP VAProfileH264High : VAEntrypointVLD VAProfileH264High : VAEntrypointEncSlice VAProfileH264High : VAEntrypointFEI VAProfileH264High : VAEntrypointEncSliceLP VAProfileVC1Simple : VAEntrypointVLD VAProfileVC1Main: VAEntrypointVLD VAProfileVC1Advanced: VAEntrypointVLD VAProfileJPEGBaseline : VAEntrypointVLD VAProfileJPEGBaseline : VAEntrypointEncPicture VAProfileH264ConstrainedBaseline: VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice VAProfileH264ConstrainedBaseline: VAEntrypointFEI VAProfileH264ConstrainedBaseline: VAEntrypointEncSliceLP VAProfileHEVCMain : VAEntrypointVLD VAProfileHEVCMain : VAEntrypointEncSlice VAProfileHEVCMain : VAEntrypointFEI VAProfileHEVCMain : VAEntrypointEncSliceLP VAProfileHEVCMain10 : VAEntrypointVLD VAProfileHEVCMain10 : VAEntrypointEncSlice VAProfileHEVCMain10 : VAEntrypointEncSliceLP VAProfileVP9Profile0: VAEntrypointVLD VAProfileVP9Profile0: VAEntrypointEncSliceLP VAProfileVP9Profile1: VAEntrypointVLD VAProfileVP9Profile1: VAEntrypointEncSliceLP VAProfileVP9Profile2: VAEntrypointVLD VAProfileVP9Profile2: VAEntrypointEncSliceLP VAProfileVP9Profile3: VAEntrypointVLD VAProfileVP9Profile3: VAEntrypointEncSliceLP VAProfileHEVCMain12 : VAEntrypointVLD VAProfileHEVCMain12 : VAEntrypointEncSlice VAProfileHEVCMain422_10 : VAEntrypointVLD VAProfileHEVCMain422_10 : VAEntrypointEncSlice VAProfileHEVCMain422_12 : VAEntrypointVLD VAProfileHEVCMain422_12 : VAEntrypointEncSlice VAProfileHEVCMain444: VAEntrypointVLD VAProfileHEVCMain444: VAEntrypointEncSliceLP VAProfileHEVCMain444_10 : VAEntrypointVLD VAProfileHEVCMain444_10 : VAEntrypointEncSliceLP VAProfileHEVCMain444_12 : VAEntrypointVLD VAProfileHEVCSccMain: VAEntrypointVLD VAProfileHEVCSccMain: VAEntrypointEncSliceLP VAProfileHEVCSccMain10 : VAEntrypointVLD VAProfileHEVCSccMain10 : VAEntrypointEncSliceLP VAProfileHEVCSccMain444 : VAEntrypointVLD VAProfileHEVCSccMain444 : VAEntrypointEncSliceLP VAProfileAV1Profile0: VAEntrypointVLD VAProfileHEVCSccMain444_10 : VAEntrypointVLD VAProfileHEVCSccMain444_10 : VAEntrypointEncSliceLP
Bug#1026060: Bug: #1026060 -- mpv: dvb playback does not work anymore
Hi Nicholas and Thomas, I have to correct my comment about "smplayer" -> got it working, my fault! I probably choose the wrong wording when saying "What now does not work: smplayer". It stopped working at the same time when mpv was upgradet to v0.35.* and stopped working. Correct I should have said "smplayer did not start working after update to mpv_0.35.1-4". But that's also not true - it now works as before after switching the settings under "General" -> "Video" -> "Output driver" from "vaapi" to "libmpv" - that's all! I only use smplayer because of the comfortable way to zap between different channels. So with using "libmpv" I have definitely higher CPU-load (~12%) compared to mpv using vaapi (~1-2%)., but that's no issue for me. For completeness here the full output when playing with mpv: $ mpv dvb://ARD [dvbin] Tuning to channel "ARD"... [dvbin] dvb_tune DVB-C ANNEX A Freq: 33000 [ffmpeg] NULL: non-existing PPS 0 referenced [ffmpeg/video] h264: non-existing PPS 0 referenced [ffmpeg/video] h264: decode_slice_header error [ffmpeg/video] h264: no frame! [ffmpeg/video] h264: non-existing PPS 0 referenced [ffmpeg/video] h264: non-existing PPS 0 referenced [ffmpeg/video] h264: decode_slice_header error [ffmpeg/video] h264: no frame! [ffmpeg/video] h264: non-existing PPS 0 referenced [ffmpeg/video] h264: non-existing PPS 0 referenced [ffmpeg/video] h264: decode_slice_header error [ffmpeg/video] h264: no frame! (+) Video --vid=1 (h264 1280x720 50.000fps) (+) Audio --aid=1 (ac3 2ch 48000Hz) File tags: Title: ARD [ffmpeg/video] h264: co located POCs unavailable [ffmpeg/video] h264: co located POCs unavailable Using hardware decoding (vaapi). AO: [pipewire] 48000Hz stereo 2ch floatp VO: [gpu] 1280x720 vaapi[nv12] AV: 00:02:42 / 00:02:45 (98%) A-V: 0.000 Cache: 3.3s/4MB Exiting... (Quit) Info regarding my GPU: Alder Lake CPU Core i5-12400 Firmware für UHD-Grafik 730: # dmesg | grep firmware [0.994151] i915 :00:02.0: firmware: direct-loading firmware i915/adls_dmc_ver2_01.bin [0.994647] i915 :00:02.0: [drm] Finished loading DMC firmware i915/adls_dmc_ver2_01.bin (v2.1) [0.999702] i915 :00:02.0: firmware: direct-loading firmware i915/tgl_guc_70.bin [0.999828] i915 :00:02.0: firmware: direct-loading firmware i915/tgl_huc.bin [1.086191] i915 :00:02.0: [drm] GuC firmware i915/tgl_guc_70.bin version 70.5.1 [1.086192] i915 :00:02.0: [drm] HuC firmware i915/tgl_huc.bin version 7.9.3 If you need more information to enable/improve vaapi for this GPU please let me know. Regards, Alf Am 23.04.23 um 01:21 schrieb Nicholas D Steeves: Dear Thomas and Alf, Thank you for confirming that this fix for DVB support works as it should. Thomas, if you have a few minutes of free time, would you please review the rest of this email, and consider verifying whether or not mpv_0.35.1-4 introduces a regression in smplayer? I hypothesise that mpv_0.35.1-3 works no better, but we need to be sure that mpv_0.35.1-4 doesn't cause any harm...if it does then smplayer will need a fix too (maybe just a rebuild). Alf writes: (+) Video --vid=1 (h264 1280x720 50.000fps) Ok, h264. (+) Audio --aid=1 (mp2 2ch 48000Hz) File tags: Title: arte HD(Unitymedia) [ffmpeg/video] h264: co located POCs unavailable Here is a thread about what this message means: https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg80351.html Using hardware decoding (vaapi). AO: [pipewire] 48000Hz stereo 2ch s16p VO: [gpu] 1280x720 vaapi[nv12] "nv12" is a colour space and pixel format thing. Yes, I had to look this up, because I've never seen "nv12" before. https://wiki.videolan.org/YUV
Bug#1026060: mpv: dvb playback does not work anymore
Hi James, James Addison writes: > > Thanks, Nicholas! > You're welcome! Also, yes, your hypothesis about DVB support being lost when the Debian packages adapted to upstream's waf-to-meson change was correct. The way always screen for this type of thing is using the "elpa-git-timemachine" Emacs package. You checkout a repository, open debian/rules, "M-x git-timemachine", and then using the "p" key to step back through the history of the file, and then use "f" to step forward to flip back. There are other ways to achieve this results, of course. 'just saying, this was something you could have fixed, had you needed/wanted to ;) > Although I don't have a DVB device to test with locally, the fix makes sense > to me, and I'm glad to read from Alf's report that it is working. > If you have a moment, could you confirm that it didn't break smplayer for you? The release team will want confirmation on way or the other. Best, Nicholas signature.asc Description: PGP signature
Bug#1026060: Bug: #1026060 -- mpv: dvb playback does not work anymore
Dear Thomas and Alf, Thank you for confirming that this fix for DVB support works as it should. Thomas, if you have a few minutes of free time, would you please review the rest of this email, and consider verifying whether or not mpv_0.35.1-4 introduces a regression in smplayer? I hypothesise that mpv_0.35.1-3 works no better, but we need to be sure that mpv_0.35.1-4 doesn't cause any harm...if it does then smplayer will need a fix too (maybe just a rebuild). Alf writes: > (+) Video --vid=1 (h264 1280x720 50.000fps) Ok, h264. > (+) Audio --aid=1 (mp2 2ch 48000Hz) > File tags: > Title: arte HD(Unitymedia) > [ffmpeg/video] h264: co located POCs unavailable Here is a thread about what this message means: https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg80351.html > Using hardware decoding (vaapi). > AO: [pipewire] 48000Hz stereo 2ch s16p > VO: [gpu] 1280x720 vaapi[nv12] "nv12" is a colour space and pixel format thing. Yes, I had to look this up, because I've never seen "nv12" before. https://wiki.videolan.org/YUV > AV: 00:11:15 / 00:11:19 (99%) A-V: 0.000 Cache: 4.1s/5MB > > Hardware here is a quite old "Sundtek TV-Stick" from 2017 with their driver. > I am watching DVB-C television with it and the channels.conf is unchanged. > Thank you for noting the hardware you tested with, as well as the type of network that you're using to receive DVB. > THANKS for your fast response and the fix! > You're welcome :) > What now does not work: "smplayer". It only plays sound but no video. > SMplayer-Protocol continously spits huge amounts of these messagen: > [12:23:52:227] MPVProcess::parseLine: "[vo/vaapi] vaPutSurface() failed > (invalid parameter)" > When did this work previously? Is this a regression for non-DVB sources (like playing normal files)? "[vo/vaapi] vaPutSurface() failed (invalid parameter)" is a vaapi error emitted by mpv. I suspect that your smplayer config is different than your mpv config, and that the smplayer config is setting up vaapi acceleration and output in a wrong way. You can try running smplayer and mpv verbosely, and then comparing the output, as well as comparing their configuration. The output driver configuration should be found here: ~/.config/mpv/mpv.conf to ~/.config/smplayer2/smplayer2.ini If it's not a configuration issue, then maybe smplayer works fine with all yuv420p sources, and that it's only nv12 sources that pose a problem? It may also be that your your vaapi hardware can't handle nv12, and mpv (directly) can detect this and uses ffmpeg to convert the stream, whereas this autodetection doesn't work with smplayer+mpv. > But that's not an issue as long as "mpv" does the job. > Wonderful :) It's also important that the new mpv version doesn't cause a regression in smplayer, especially something like breaking playback of typical yuv420p files. The release team will want to know that we're not robbing Peter to pay Paul. Cheers, Nicholas signature.asc Description: PGP signature
Bug#1026060: Bug: #1026060 -- mpv: dvb playback does not work anymore
Hi, I can confirm that DVB playback is now working again for me with mpv_0.35.1-4_amd64.deb. Thanks!
Bug#1026060: mpv: dvb playback does not work anymore
Source: mpv Followup-For: Bug #1026060 X-Debbugs-Cc: s...@debian.org Thanks, Nicholas! Although I don't have a DVB device to test with locally, the fix makes sense to me, and I'm glad to read from Alf's report that it is working. Regards, James
Bug#1026060: Bug: #1026060 -- mpv: dvb playback does not work anymore
Found detailled information on my hardware as I noted on first installation in Debian-Stretch: $ /opt/bin/mediaclient -e List of Media Hardware Devices device 0: [Sundtek MediaTV Pro (USB 2.0)] DVB-C, DVB-T, ANALOG-TV, FM-RADIO, REMOTE-CONTROL, OSS-AUDIO, RDS [INFO]: STATUS: STANDBY [BUS]: ID: 3-1.4 [SERIAL]: ID: U120820070038 [DVB-C,DVB-T]: FRONTEND: /dev/dvb/adapter0/frontend0 DVR: /dev/dvb/adapter0/dvr0 DMX: /dev/dvb/adapter0/demux0 [ANALOG-TV]: VIDEO0: /dev/video1 VBI0: /dev/vbi0 [FM-RADIO]: RADIO0: /dev/radio0 RDS: /dev/rds0 [REMOTECONTROL]: INPUT0: /dev/mediainput0 [OSS]: OSS0: /dev/dsp0
Bug#1026060: Bug: #1026060 -- mpv: dvb playback does not work anymore
Am 19.04.23 um 23:02 schrieb Nicholas D Steeves: Dear Alf and James, I agree that DVB support is important, and I just uploaded mpv_0.35.1-4 (to sid/unstable). That release will close this bug, but please test this it ASAP and confirm that it works with your DVB hardware. Yes, I know it might take a day to become available...sorry about that. I just updated mpv to version 0.35.1-4 from Sid - and can confirm that the issue has been fixed. All works as some time ago with v34.*. ... (+) Video --vid=1 (h264 1280x720 50.000fps) (+) Audio --aid=1 (mp2 2ch 48000Hz) File tags: Title: arte HD(Unitymedia) [ffmpeg/video] h264: co located POCs unavailable Using hardware decoding (vaapi). AO: [pipewire] 48000Hz stereo 2ch s16p VO: [gpu] 1280x720 vaapi[nv12] AV: 00:11:15 / 00:11:19 (99%) A-V: 0.000 Cache: 4.1s/5MB Hardware here is a quite old "Sundtek TV-Stick" from 2017 with their driver. I am watching DVB-C television with it and the channels.conf is unchanged. THANKS for your fast response and the fix! What now does not work: "smplayer". It only plays sound but no video. SMplayer-Protocol continously spits huge amounts of these messagen: [12:23:52:227] MPVProcess::parseLine: "[vo/vaapi] vaPutSurface() failed (invalid parameter)" But that's not an issue as long as "mpv" does the job. Alf
Bug#1026060: Bug: #1026060 -- mpv: dvb playback does not work anymore
Hi Thomas, I didn't notice that you weren't in the CC list of the following email. Sorry about that, and I'm sending you a copy now. Please test 0.35.1-4 (in sid) as soon as you can! It's now been uploaded, and I don't have the hardware to confirm that DVB support didn't break upstream (highly unlikely, but this needs to be tested for the unblock request). Thanks, Nicholas Nicholas D Steeves writes: > Dear Alf and James, > > I agree that DVB support is important, and I just uploaded mpv_0.35.1-4 > (to sid/unstable). That release will close this bug, but please test > this it ASAP and confirm that it works with your DVB hardware. > Yes, I know it might take a day to become available...sorry about that. > > Thank you for your participation in this bug. It's conceivable that > there are people who depend on mpv's DVB support to follow news/alerts > that impact their safety, so I believe that it's important to continue > to provide that support in bookworm. > > I also preemptively filed an unblock request with the release team, > because I have faith that you will test 0.35.1-4 as soon as it becomes > available. > > Best, > Nicholas signature.asc Description: PGP signature
Bug#1026060: Bug: #1026060 -- mpv: dvb playback does not work anymore
Dear Alf and James, I agree that DVB support is important, and I just uploaded mpv_0.35.1-4 (to sid/unstable). That release will close this bug, but please test this it ASAP and confirm that it works with your DVB hardware. Yes, I know it might take a day to become available...sorry about that. Thank you for your participation in this bug. It's conceivable that there are people who depend on mpv's DVB support to follow news/alerts that impact their safety, so I believe that it's important to continue to provide that support in bookworm. I also preemptively filed an unblock request with the release team, because I have faith that you will test 0.35.1-4 as soon as it becomes available. Best, Nicholas signature.asc Description: PGP signature
Bug#1026060: mpv: dvb playback does not work anymore
Source: mpv Followup-For: Bug #1026060 X-Debbugs-Cc: patchesthomas@web.de, alf.debian...@gmx.de Hi, I haven't 100% confirmed this, but from some inspection it looks like DVB support may be disabled-by-default based on the meson options[1] in the source package for mpv. The upstream source began using meson from version 0.35 onwards[2], so that could fit as an explanation. FWIW: Debian's packaging has (both in the past[3], and currently[4]) included build configuration to enable DVB.. so this may likely be a regression as a result of those upstream build system changes. Thanks, James [1] - https://sources.debian.org/src/mpv/0.35.1-3/meson_options.txt/#L14 [2] - https://github.com/mpv-player/mpv/pull/8840 [3] - https://sources.debian.org/src/mpv/0.32.0-3/debian/rules/#L8 [4] - https://sources.debian.org/src/mpv/0.35.1-3/debian/rules/?hl=8#L8
Bug#1026060: mpv: dvb playback does not work anymore
As Thomas Viehweger wrote, DVB support ist missing since upgrade to v 0.35.*. It can be clearly seen by executing mpv --list-protocols "dvb://" is no longer included. I searched all change.logs on Debian and also Upstream (https://github.com/mpv-player/mpv/releases) and I could not find any entry regarding removal/depreciation of dvb protocol. So it is definitely a regression and the severity of the bug should be raised to "serious". Regards, Alf
Bug#1026060: mpv: dvb playback does not work anymore
Package: mpv Version: 0.35.0-3 Severity: important mpv 'dvb://Das Erste HD' fails with No protocol handler found to open URL dvb://Das Erste HD The protocol is either unsupported, or was disabled at compile-time. With mpv-0.34.1-1+b5 this was working.
