One particular channel not working

I just upgraded to the most recent release. I now have one particular channel that is not working. I select the channel and all I get is “buffering” in the upper right corner.

I turned on debugging and captured a log file. However, I don’t see a way to attach the log file to this topic.



Do I assume correctly that with “channel” you refer to a TV channel from TVHeadend?

For you question of “attaching” a log. Just use the log upload function from the MyOSMC menu and share the URL that you see here.

I am sorry, I did not give additional information with this post. I have an HD HomeRun Prime with a cable card as my source. I use NextPVR as my backend PVR.

I can watch the channel just fine at the server, but it won’t display on OSMC.

I’ll get that link posted as soon as I can.

Thank you.


Not sure why you deleted the post in which you gave the log file.
Suggest to give the log file and name the channel that you have problems with

I didn’t know all of the details that would be included in the logs. There was more information in the logs than what I wanted posted to a public forum. Do you want or need only debug logs, or are there additional logs that you need? Instead of posting “everything”, I’ll be selective and post only what you need.



The log uploader takes care that no important information is uploaded
Anyhow the kodi.log would be a minimum requirement.
Also let us know which channel you try to watch

I saw information related to my internal environment. I don’t want that information published to a public forum. I’ll get the kodi.log uploaded as soon as I can.

Thank you .


I am going to close this issue. As I was working getting a new debug log, the channel just suddenly started working.

For future reference, is there another way to upload logs? If I have to upload logs, I would prefer to edit them and make sure that no information related to my environment is published. I would much rather pull them off the the Pi, edit them, then upload them somewhere.

Thank you.


There are no details in your log that would expose you to any risk. The fact that anyone may have a device named Win9Home99 on port 666, means nothing to anyone outside the local network. If we can see that your device’s local network address is, guess what, 20% of the people with a wireless network in their home have a device with this same address within their LAN that cannot be accessed by anything outside their router/firewall. Nothing here is identifiable to you or puts you at any risk.

If you really want to, you can choose to copy the logs to the SD card instead of upload them.

This will create a file called /boot/uploadlog.txt. You can view this file to see if you are happy with it, then you could upload it with:

paste-log /boot/uploadlog.txt

You may be correct, but I use this same level of caution at work as well. If I post a log file from a server that I’m working on to a public forum, I make the exact same edits. You may think that I’m paranoid, but in this day and age, I’d rather be a little paranoid and make sure that I protect my information than take the chance and hopefully nothing gets out there that could expose me to a potential compromise.


Thank you. I’ll give that a try next time.


Also have a look at the grab-logs command, which is the command line tool that does the same as the My OSMC log uploader. Running it with no arguments displays the command line options.

Depending on the command line options you use you can also tell it to save to uploadlog.txt, or even print the log directly to stdout instead of saving to another file. An example would be:

grab-logs -A -P | less

Which would capture all logs, and print them to the screen (only) paged via piping to less.

Also until you post the URL to the log in the forum nobody except the server admin (Sam) could access the log, and he wouldn’t know who the log was from anyway, (as they are submitted in anonymous form) so you have time to preview your own uploaded log before other users can see it by visiting the URL before posting it in the forum.

I’m sorry but you really don’t seem to understand how networking works. This is not a matter of an over abundance of caution but the fact that from OUTSIDE your LAN, the info in the logs means nothing to the “best hacker in the world”, even if they did want your puppy pictures and access to your retirement fund which certainly pales in comparison to the corporate money that this “best hacker in the world” would surely see as a better investment of his time.


I understand perfectly well how networking works. Its not about someone gaining access to my puppy pictures, its about protecting my person identity and my security. I use this exact same level of caution in all of my online actives, work and personal. When it comes to identity protection, and security, I am very anal about what I put out in the public domain. I don’t put anything in the “cloud”. I don’t trust the cloud and I even work for a “cloud service provider”, and I’m not the only one in my company that has the same feelings and opinions.

I’ve been in this business for far to long to know how easy it is to gain access to personal information and I value my personal information and protect it as best as I can. I can’t stop everything, but the items that I can block I do.


I’m still having issues with this particular channel. It started working as soon as I started this thread, but has since stopped working. When I select the channel, I get “buffering” at 0% in the upper right corner, but it never goes beyond that. All other channels seem to work just fine.

As soon as I get a chance to “collect” logs and get them uploaded I will.

Thank you.


Good for you. It’s my job to ensure that other users of OSMC are assured that providing logs for the purposes of troubleshooting/debugging puts them at zero risk. The idea that pruning local network addresses from logs would make anyone more safe from identity theft or other compromise is completely false, without factual/technical merit, and very likely result in time wasted and/or inability to accurately resolve/debug issues that may or may not be attributable to network problems.