[BUG/FEATURE?] Playback on LG TV WebOS does not render video files

[Jamalarm]

Describe the bug

(Note: wasn't sure about BUG or FEATURE here, you don't explicitly mention embedded browsers as a supported platform).

When running the pi as a server in --headless mode, and accessing http://pi:5555/splash on the embedded web browser of an up-to-date LG TV (running WebOS), everything will work perfectly except that the video stream does not render.

To Reproduce
Steps to reproduce the behavior:

1. Host a pikaraoke deployment somewhere with --headless enabled
2. Open the "Web Browser" app on an LG TV (mine is a C2)
3. Navigate to http://pi:5555/splash
4. Enqueue a song

Expected behavior
Video and Audio should both play.

Actual behavior
ONLY Audio plays. I can provide a video if this would be useful but it's basically just the normal PiKaraoke interface with a black background and the audio of the song playing. Everything else renders perfectly.

Platform (please complete the following information):

• Server Hardware: Have tested this on a Pi 5 and a Pi 3. Right now I am running on Docker.
• Browser: Embedded WebOS

Additional context
I have verified that this is not related to a network setup on the Pi side, as my OSX laptop and my Windows Desktop can both access http://pi:5555/splash and stream the video+audio fine. Also the LG web browser is definitely capable of streaming video, Youtube functions fine along with every other streaming video site I've tried.

The tricky part is that you cannot actually access a debug menu in the browser on the TV, so I'm struggling to think of how to get hints on what needs to change. I can easily test tweaks to the video streaming for you if you have any ideas on what might be the issue.

It would be great if this could be fixed because it would allow any owner of an modern LG TV (of which there are many as they currently make the best TVs) to just run pikaraoke natively directly on the TV.

[vicwomg]

There are a few reasons why video won't play in a specific browser:

• Browser does not support pikaraoke's mp4 encoding (usually do to the fact that the file is being generated in realtime, therefore incomplete)
• Browser doesn't like the http headers we're sending
• Browser does not allow autoplay (that's what the initial confirmation prompt is about)

Tip: you can add ?confirm=false to the splash screen URL to disable the prompt at the beginning. If the browser allows autoplay, this is fine, but most major browsers don't.

Chrome is the most forgiving about these things. Safari and Firefox, not so much. The fact that the browser in question plays audio seems to indicate it might be one of the first two issues.

In this branch:
#447

I have implemented a new single-port operation of pikaraoke that transcodes completely to disk before sending off. You need to specify the --buffer-fully-before-playback CLI option. This also sends better headers because we know the full filesize. Browsers like safari require that for mp4.

See if it works better for this embedded browser and report back

[Jamalarm]

I've run a test using the rc-1.8.0 docker tag that you pushed an hour ago, as far as I can tell this single-port fix is included.

Unfortunately the behaviour is the same, audio perfect, everything in the UI renders fine, just no video.

Edit: sorry I just realised I forgot to specify the extra arg. Testing again...

That fixes it! Video and audio plays fine now! I can probably go ahead and close this issue and just use the RC branch for now?

[vicwomg]

That fixes it! Video and audio plays fine now! I can probably go ahead and close this issue and just use the RC branch for now?

Wow, I'm actually quite surprised. That's great!

[vicwomg]

Still wrapping up the rc, I am adding some more goodies and want to test it thoroughly on an actual pi, but don't currently have access to one.

[vicwomg]

btw, the name of the buffer flag will change to --complete-transcode-before-play or -c

[Jamalarm]

want to test it thoroughly on an actual pi, but don't currently have access to one.

Happy to help out if there are specific things I can test for you. Just give me a shout.

[Jamalarm]

Hey @vicwomg, thought I'd update you with a limitation I have found in testing on embedded TV browsers.

On OLED TVs they tend to sleep the screen pretty aggressively to avoid burn-in. Unfortunately playing a video doesn't seem to "reset" the inactivity counter. While the video is playing the screen does not sleep, but the second the video ends the screen will go to sleep. When the next video starts the screen will wake up after about a second, and so on. Sleep-wake-sleep-wake with each queued video.

I did some reading (asked ChatGPT :) ), apparently there are two options for this:

1. Use the JS Wakelock API to explicitly tell the browser to not sleep - cleanest but not supported on all browsers
2. Play a secret invisible hidden video on a loop somewhere on the page when just displaying the interface

It would be good to implement one of these because it would generalise to any headless deployment that is being displayed on something that might decide to go to sleep due to "inactivity".

[vicwomg]

Version 1.8.0 has the background music on the splash feature. I'm curious if streaming audio keeps the screen on in these scenarios

I've done stuff like the secret invisible hidden video loop on another before. It feels like a bit of a hack, but if it works it works.

[Jamalarm]

I tested it out, the background music is playing but the screen actually stays off. The TV is too smart and thinks it is saving the screen by allowing streaming audio when there's no video :)

[Jamalarm]

Separate question: Do you have anything in the code for doing hardware-accelerated transcode? By default docker-compose doesn't expose the GPU to the container and the --complete-transcode-before-play adds about a 10 second delay before each song plays. Not a disaster obviously but was wondering if I could speed that up by exposing the GPU to the container.

[vicwomg]

I tested it out, the background music is playing but the screen actually stays off. The TV is too smart and thinks it is saving the screen by allowing streaming audio when there's no video :)

In that case it would seem that we will need to experiment with enabling Wakelock. If I go the ambient video route, might be nice to actually show an interesting backdrop video instead of flat black.

Separate question: Do you have anything in the code for doing hardware-accelerated transcode? By default docker-compose doesn't expose the GPU to the container and the --complete-transcode-before-play adds about a 10 second delay before each song plays. Not a disaster obviously but was wondering if I could speed that up by exposing the GPU to the container.

What's your hardware? On faster CPUs I find the complete-transcode time to be not very long at all, certainly not 10 seconds.

I'm not sure if you're running docker on a pi, but if so I think this might be tricky. ffmpeg builds for raspberry pi do include some hardware GPU encoders in the form of the h264_v4l2m2m encoder:

pikaraoke/pikaraoke/lib/ffmpeg.py

Line 19 in 2b1c5dd

default_vcodec = "h264_v4l2m2m" if supports_hardware_h264_encoding() else "libx264"

Pikaraoke does use this if run natively on a pi, but within a container my guess the the ffmpeg version does not include it, nor does it detect the running device as a pi.

[vicwomg]

Researching further, Wakelock only works over https. I think background video is the only universal option

[vicwomg]

Just pushed 1.9.0
https://github.com/vicwomg/pikaraoke/releases/tag/1.9.0

It features a configurable background mp4 video, a default video is provided. This will play on the splash screen in the background. LMK if that keeps the screen saver from coming on.

[Jamalarm]

I've tested it. The background video seems to have a couple of bugs to it. I think it is rendering over some bits of text and the QR code sometimes. Also it seems to play sporadically and not smoothly for some reason, so it will play and then stall and then play and then stall.

Testing the stay-awake: bit of a mixed bag. After a song finishes:

1. The TV sleeps immediately
2. You hear that new "clapping" sample that plays (screen still dark)
3. TV Wakes and car video is playing, but no other elements are visible (no QR code, no up next)
4. Video stutters and eventually stops
5. TV goes back to sleep
6. TV sleeps until another song is queued, at which point it wakes up and displays that video properly

Let me know if you want me to test anything else or take a video or something.

[vicwomg]

My guess is the TV's browser is struggling with the mp4 encoding of the background file. Try supplying your own mp4 via the command line option (you can even point it to a pre-downloaded mp4 karaoke file from your download directory) and see if it plays better. If so I can mess with the ffmpeg settings.

In any case it seems to me that the screen off behavior is extremely aggressive. I would expect it to behave more like resetting idle timer, not like a hard stop after every video. Is there really no setting in the TV to disable this?

[Jamalarm]

In any case it seems to me that the screen off behavior is extremely aggressive. I would expect it to behave more like resetting idle timer, not like a hard stop after every video. Is there really no setting in the TV to disable this?

Yeah I very much agree with you there! It's hyper aggressive.

After some digging around I've found that, specifically with LG's OLED TVs, they have removed any option to disable the screensaver. ALSO I found a thread where they confirmed that the WakeLock API actually isn't implemented anyway.

One thing I was going to say btw: With the Docker deployment, it's actually quite hard to find out what all the options are and how to use them. It would be super useful to have a list of the flags in the documentation, as the only other way to get hold of them is to either install the app normally and run --help or docker exec your way into the container and run --help there

[vicwomg]

The command line options are in the main wiki page. I don’t put them in the readme because they go out of date rather quickly and it’s easier to update the wiki

…

On Sun, Jan 19, 2025 at 1:56 AM Tom ***@***.***> wrote: In any case it seems to me that the screen off behavior is extremely aggressive. I would expect it to behave more like resetting idle timer, not like a hard stop after every video. Is there really no setting in the TV to disable this? Yeah I very much agree with you there! It's hyper aggressive. After some digging around I've found that, specifically with LG's OLED TVs, they have removed any option to disable the screensaver. ALSO I found a thread where they confirmed that the WakeLock API actually isn't implemented anyway. One thing I was going to say btw: With the Docker deployment, it's actually quite hard to find out what all the options are and how to use them. It would be super useful to have a list of the flags in the documentation, as the only other way to get hold of them is to either install the app normally and run --help or docker exec your way into the container and run --help there — Reply to this email directly, view it on GitHub <#450 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA7KXNRCUUZYNVWK3SBDPA32LNZF5AVCNFSM6AAAAABUITQ7USVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMBQG44DOOBSGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>