My RPI 3/OSMC system has been running great for quite some time. In fact, I watched some recorded videos last night. Then, this morning I came downstairs to catch a show while I was eating breakfast and I found my PVR in a constant reboot. If do a restart it goes thru, what now appears to be, a partial boot up sequence on screen (gets to the blue screen with the OSMC logo, goes a bit further) and then it shows the “sad face”, goes dark for a few moments and then back to sad face, and continues to recycle…my sad face →
Idk for sure, but there may have been a brown out last night (clocks are OK, tho).
I can get in thru ssh just fine (well, mostly…once it did a reboot and kicked me out. As I write this it is in a constant reboot mode).
I did a " tail -F /home/osmc/.kodi/temp/kodi.log" to see the boot process and since I couldn’t remember if I should post it here, I put it on paste.bin:
One thing I noticed right off is is there is a CProfileManager that can’ seem to open a //masterprofile/profiles.xml and that’s the point where the system resets.
Definitely open to any insight as to why and how I can correct the problem.
Does that mean I need a new SD card? Also, does it make any difference that I have the system set up with a hard drive (went thru the process of moving the system to it way back when)? What does that mean for what’s stored on the hard drive?
You didn’t indiate which PVR client you are using but it sounds very much like the issue I had last night / today with the unofficial HDHomeRun PVR client. See this thread. . If this is the PVR client you are running then the fix is:
SSH into OSMC and go to .kodi/addons/pvr.hdhomerundvr/
Feels a bit like we’e in a time lag with each other…
I did the mv .kodi .kodi.save and .kodi.save was moved under .kodi so the system must have gone back to default (noticed all my addons were then gone from .kodi). I then moved .kodi.save back up 1 level and renamed it back to .kodi (1st renaming .kodi.save to .kodi.orig). Then it was back to the problem.
In my 1st posting where I did the “tail…” I saw the same problem about failure to open profiles.xml. Is there anyway to try and restore most, if not, all of it somehow?
Yes, I could move it to my Fedora 30 box, but that would be a pain. No way I can do an fsck on it while in the RPI 2/OSMC system?
Just noticed something else. Not sure if it’s the same one referenced in the logs…there’s a profiles.xml under.kodi/userdata and it shows 0 bytes and when I open it it’s empty. May explain why it can’t be “opened”. The one located under .kodi.orig (which is what I named the .kodi that showed up after I did the mv… and “start”) has about 1KB and does have xml text in it.
Seems like my orig profiles.xml got mucked up somehow. Wonder if a copy exists somewhere that I can use to restore it?
Not that I actually remember I will going forward.
It means a lot of work to get the system back to where it was. Or, can I move everything (like addons, userdata,etc.) except the bad profiles.xml over to the new .kodi and avoid a lot of work? Or is that a disaster waiting to happen?
Or, can I simply keep the .kodi with the bad profiles.xml and replace the bad one with the new, good one?
I copied over the new, good profiles.xml to the orig .kodi directory. Everything is pretty much back to normal. At first glance, the only things that are not back the way I had them are changes to the main and submenus I had made. I expect I may find other settings that have to be redone, but it feels like it’s 90% or more there. Lucked out.
As soon as I have things back where I want them, I’ll make a copy of the .kodi directory, just in case. I also plan to get more committed to backups.
Thanks much for your time and help. I truly appreciate it!!
I am using the HDHomeRunPVR client, but if you’ve followed this thread it turned out something glitched my profiles.xml file (basically zeroed it so now I have things back to a more normal state. Still some work to do tho.
Thx for the suggestion. I’ll keep it in mind next time something similar happens and it’s not my profiles.xml file
That would prob’ly be the smart thing to do. When I get the chance I will do exactly that.
It’s not self-powered and since it’s a 3-1/2" HDD it requires external power to run it from a USB port (I use an active USB-SATA interface cable to connect the drive since that’s how the RPI 3 rolls with HDDs). So, I can do it, but it’s a pain. It might be just as easy to actually do the testing “in system”.