Check the container environment variables to make sure the username and password are correct.
see Frndly TV for Channels - #1353 by chDVRuser
Of course, for Fubo they would be
[email protected]
FUBO_PASS=Monkey123!
And I'm sure the container works with IPv4 and not just IPv6
container also crashes on reboot but I found the following workaround
using:
sudo crontab -e
set the following script to run on reboot
#!/bin/sh
sudo docker kill vlc-bridge-fubo
sleep 5
sudo docker rm vlc-bridge-fubo
sleep 5
"insert docker run command here"
sleep 5
sudo docker restart vlc-bridge-fubo
sleep 5
sudo docker restart vlc-bridge-fubo
sleep 5
sudo docker restart vlc-bridge-fubo
sleep 5
sudo docker restart vlc-bridge-fubo
sleep 5
sudo docker restart vlc-bridge-fubo
sleep 5
curl -s http://localhost:8089/admin/settings/sources#
Unusual problem.
What are you running the container on.
I have the same problem, it takes several restarts to get it going again...
I am running it on ubuntu 25.04 with docker 28.3.3 on a dell tower plus desktop (ebt2250) with a core ultra 7 265 cpu, 16gb ram, a nvidia rtx 2000 ada and an x550-t2 nic. I hope that is enough info 
I'll back out of the conversation since I no longer have a Fubo sub and don't even get the Free channels on their website. I ran the latest version of the container with no errors, but since I don't have a sub, I couldn't even get a playlist. I can login to their website, but am not offered a trial sub anymore. It was great back in the day when they had more channels, but their sub is too costly for my current needs, so I'll stick with YTTV for now 
I think this is happening everytime when I update to the latest pre-release, then the Fubo Docker stops working. At least that is what I am finding so far...Today (after doing the pre-release update) it took a couple of minutes and then it came back...
For me, this is a new issue, it only started happening in the past 2-3 weeks. I've tested a few scenarios to see what triggers it. It doesn't trigger when I update to the latest CDVR prerelease, but it seems most common after restarts to the vlc-bridge-fubo container, for whatever reason, be it a server restart, an update, etc.
At that point, even if I wait an hour, or wait a day, the first time I try to tune into a channel provided by this container, I have to click past this error on-screen a few times, in order to get the first stream to play:
And then, it works fine. Channel surfing to more channels from the same container work fine too.
I think that's what @techpro2004's post above is meant to workaround as well? I'm not really sure.
@GenericChannelsUser, can this sort of fix be integrated into the container itself? I don't mind having to click a few times to get the fubo-vlc bridging working when channel surfing but I wouldn't want to miss scheduled recordings because of this issue, either.
I am not sure how I would implement something that would restart the docker several times in the compose or docker code itself like @techpro2004 is doing with the crontab. I do believe that their fix is a patch on a bigger issue, or set of issues that are currently occurring.
@Fofer: I noticed the same issue as you when tuning to a channel initially and have been looking for a fix for the last week. There currently appear to be two issues of which I am not sure if they are related:
I do not know if issue 1 stems from issue 2 or if it is wholly separate. I also am not sure how to fix either issue. If anyone here has any ideas on how to fix and wants to suggest fixes here or wants to post a pull request at gitlab it would be greatly appreciated.
I am getting the following error when clicking the url (http://xxx.xxx.x.x:7777/fubo/playlist-hls.m3u):
HTTP failure 401: {"error":{"code":"INVALID_USERNAME_PASSWORD","message":"The username and/or password used for authentication are invalid","lc_message":"The username and/or password used for authentication are invalid"}}
Password works perfectly fine on Fubo and is nothing unique. Eventually it will start working again...
0.0.10 is out now and should have fixed the errors that we were experiencing.
The update adds some logic to retry login attempts 10 times before it fails now. In the logs you will see the retry attempt number and the login error message each time it tries to login. This can take up to 20 seconds to tune to the first channel, but once it is logged in it should be good to go. This should solve the problem that we were facing but if anyone has issues with it please let me know.
I also updated the new line header value error.
according to portainer, I am getting error 137 every time I reboot my server. the following script on reboot fixes it.
#!/bin/sh
sudo docker kill vlc-bridge-fubo
sleep 5
sudo docker rm vlc-bridge-fubo
sleep 5
"insert docker run command here"
sleep 20
curl -s http://localhost:8089/admin/settings/sources#
I just rebooted my server and the container started right up no problem.
Error 137 appears to be a docker error that has to do with it being out of memory. Not sure why the commands that you are running would fix that error.
I think my server has a timing issue as running the below also works. Please add a startup delay to the docker.
#!/bin/sh
sleep 5
sudo docker restart vlc-bridge-fubo
sleep 30
curl -s http://192.168.1.28:8089/admin/settings/sources#
Also, please have it have channels reload the m3u by the equivalent of the bottom line in the above code snippet.
Hmmm, I'm not getting error 137 either.
Why should the startup delay be added to the docker that everyone else uses as a workaround patch for an issue with your own server?
because, if it affects me, it probably affects others with a similar config.
but even then, it would introduce unnecessary startup delay to everybody else who has a different config — or the same config, but without your own specific “out of memory” issue
Really don't want to turn this thread into an argument. I just thought my suggestion would be helpful Don't want to fight about it.
Great that the log helps track how many attempts were needed. Once it worked on the first try for me. Most recently I saw the error message appear on the TVOS screen and had to press play a second time to try again. Checking the docker log it took 13 tries in total to complete. I'll keep track and see the highest number of tries needed over the next couple days - might be defaulting to more than 10 tries would help.
Highest number of tries over 2 days was 16, most times less than 10. Maybe a shorter time between retries is also a possibillity. The last week or two, before the update, I pressed "play" on the remote very quickly until it "worked". Thanks so much for the work you've done on the container, I've really enjoyed easily viewing the Nats and Orioles baseball games on our local RSNs again this summer without having to change apps...