dep via tde-users wrote: This was too bothering for me so I put a TFTP and configured to boot from the server (I have RPi2/3/4 diskless). I am not sure if it is Firefox issue at all. IMO the problem is (as mentioned elsewhere) that we do not use DBus. Firefox would use org.freedesktop.ScreenSaver interface to disable screensaver, dimming, hibernation etc. while you are watching something. I completely disabled the screensaver, but I was just looking (I mean exactly before I read this message) into the DBus spec and into the code (kdesktop_lock) and thinking how much effort would be to implement.

dep via tde-users wrote: I am not 100% sure - may be 80%, I have not checked details for proof. Best TV is no TV - it does not cost anything and is very secure :) TV turned into crap all over the world in past decades - here and there a documentary or so worth to watch. This is why I abandoned the DVB-T stick.

J Leslie Turriff via tde-users wrote: if it were better I would be using it :)

said Thierry de Coulon via tde-users: | I do use Kaffeine (and it works OK for me), but the KDE version. Not | that I really prefer it, but it manages to find my cable channels, a | thing "Taffeine" no more does. That's the issue. I'm interested in it only for watching over-the-air television. I have no cable, streaming only, and the miserable crooks who run the phone company here have made sure to configure it that we don't have TV, internet, or phone anytime we might actually need it, such as threatening weather. I hope they take up the hobby of helicoptering in northern Iran in the fog. So when I need broadcast TV I'm likely to really need it. With Kaffeine I get the picture perfectly, but the audio is silent except for occasional loud clicks. The mpeg decoder is dlearly not there or not working -- won't work on VLC, either, though Kaffeine is pretty much just a very nice VLC add-on so that's not a surprise. I have done searches on every line in the lengthy error messages and have learned nothing. I suspect it will turn out to be something extremely simple. But I do not know what that is. -- dep Pictures: http://www.ipernity.com/doc/depscribe/album Column: https://ofb.biz/author/dep/

said E. Liddell via tde-users: | On Thu, 23 May 2024 17:57:51 +0000 | | dep via tde-users <users(a)trinitydesktop.org> wrote: | > As I said, no sound. The occasional crackle or alarming pop. Video is | > fine. EPG is fine. Started it in a terminal and after the expected | > bitching about not liking my desktop, this: | > | > [code] | > mpeg2_v4l2m2m @ 0x7fff5804e100] Could not find a valid device | > [mpeg2_v4l2m2m @ 0x7fff5804e100] can't configure decoder | > [00007fff58013710] avcodec decoder error: cannot start codec | > (mpeg2_v4l2m2m) [00005556238c9770] main audio output error: too low | > audio sample frequency (0) [00007fff58053150] main decoder error: | > failed to create audio output [mpeg2_v4l2m2m @ 0x7fff5804e100] Could | > not find a valid device [mpeg2_v4l2m2m @ 0x7fff5804e100] can't | > configure decoder | > [00007fff58013710] avcodec decoder error: cannot start codec | > (mpeg2_v4l2m2m) [00007fff40006870] gles2 gl: Initialized libplacebo | > v4.208.0 (API v208) [mpeg2video @ 0x7fff5804e100] get_buffer() failed | > [mpeg2video @ 0x7fff5804e100] get_buffer() failed (-12 (nil)) | > [/code] | | The thing that stands out to me here is the "v4l" bit showing up in one | of the codec names. That last character is an L, not a 1, so it's | presumably referring to Video4Linux, which is a set of kernel drivers | for video hardware. The sequence seems to suggest that v4l isn't quite | working right and can't get the audio feed. | | kaffeine doesn't link v4l itself, but picks it up through xine-lib. | xine-lib may be linking it directly or picking it up through ffmpeg, | depending on how your distro has it set up. The presence of "avcodec" | in the trace suggests ffmpeg's involvement. | | So I'd start at the kernel level, verify that the correct drivers are | available and being attached to the correct devices, then move upward | through ffmpeg and xine-lib. (If VLC, which uses libmpeg2 for mpeg2 | decoding, happens to work, that would practically be a smoking gun | pointing at ffmpeg or xine.) Thank you. A couple of things that may or may not be pertinent. First, both VLC and Kaffeine work just fine with everything else. Second, support for the TV device, a Hauppauge 1595, has supposedly been in the kernel for years now. This makes me hesitant to d/l Hauppague's stuff, which lists itself as working in Ubuntu 14.04 -- 10 years old. I've gotten and run w_scan_cpp, many times, making channels.conf (and many other formats, all the possibilities) in hope of narrowing the problem, in that Kaffeine and VLC are essentially the same thing. Apparently mplayer gets its signal some other way, and if I can figure out how to work the thing I hope to learn if the issue is farther upstream. (A terminal television program seems a bit like a blind taxi driver.) The mplayer GUI is possibly the most counter-intuitive thing since emacs (or WordPerfect). There's a shortage of video programs that don't hang off VLC. Clearly. something is working, in that the Hauppauge gadget is delivering the image just fine -- it's the sound that is screwy. Added to this is the change from Pulseaudio to Pipewire, and the plethora of adapters designed to translate from one to the other. In practical terms this means that I've read and tried things that have been obviated in the last couple of years. (The web is not big on putting dates on things.) I can't help but think that there's a switch someplace that if turned from off to on or vice versa, is changed to or from alsa, something, will make it work. (Example: there is a dandy Raspberry Pi utility that duplicates the SD card in the machine. It is useful for all sorts of things, especially for making a copy of the working system on your SSD, to keep close at hand for when you break it. But when you boot the new SD, you quickly discover you're back in the system on the SSD. Reason is, and it was not easy to find, is that the duplicating program has a little checkbox, "New Partition UUIDs," that by default is unchecked. If you boot from an SD onto a device that has an SSD with the same UUID, partway through the boot it hands everything off to the SSD. There might be a reason to leave that box unchecked by default, but you cannot imagine how much trouble it has caused. What's more, there's no instant way of determining which is the booted device. I learned the trick -- check the box -- but whenever I'm fixing to boot from flopp . . . oops, SD, I make a point of changing the color of the desktop forst, to pink or something, so I can tell that the SD is what's running.) Linux audio is and always has been a lot like car dashboard wiring. Maybe you can get what's broken to work, but there's a good chance you just have to live with it. I have no idea in the world how to do diagnostics on all this. -- dep Pictures: http://www.ipernity.com/doc/depscribe/album Column: https://ofb.biz/author/dep/