LibreElec (RPI) Gathering File Info .... Hang. #230
Comments
|
Thanks for the information. I use this regularly on LibreElec with Kodi 20 Nexus (not sure the exact LibreElec version). Logs would be the next step to see what's going on. Generally for a failure right at the beginning it's usually some kind of file permissions issue - sometimes it's an issue with a particular addon where a lock is on a file (like a .so library) kills access. The addon is currently maintained. Not exactly offended at the question but am curious why people always ask that? The last commit was only 2 months ago and for something that's relatively stable that doesn't seem out of line. Many of the outstanding issues in this repo are from no follow-up on the part of the original creators after fixes or suggestions have been given. Again, not offended at the question but no other repo I work on seems to get this question. edited this as originally I said Kodi 21 but I'm on the current stable release 20.5 |
|
Hi Rob - And thanks for the reply. I'll generate some logs from both instances over the coming days and post them. Any level of logs specifically you need? It would be good to know what version you're currently running, as i have a funny feeling it last worked for me on version 11.0.4 and both instances are now on 11.0.6 (latest at time of writing) In regards to permissions, i've chown'd the remote location recursively with guest user access and recursively set permissioning levels to 777 (for testing purposes.) I'm wondering whether another addon is potentially causing it issues? I do run my instances quite minimally and dont run any dodgy repo's or illegal streaming addons. (no streaming addons on one instance and netflix & amazon on the other, but both have the issue) mainly just local file playback. The apology was mainly due to not wanting to be badly recieved for asking. As i'm very thankful it exists and rely it on for backup purposes. I wanted to double check it was maintained as i was seeing some unanswered issues and just wanted to check prior to save myself a lot of time troubleshooting my instances to infinity expecting to find a fix. Not being a dev myself, i dont know enough about your build pipeline for this project and whether you had some automated build process potentially sanity checking it, running tests or patching it and uploading the changes automatically to this github project, i saw most files in the home folder had long standing dates into the years. (altough i understand a project like this dosnt need to change drastically often!) I've also been having the issues for months. And normally have witnessed these issues to go away on their own when addon's are updated in line with the libreelec updates. But this one as of yet is still problematic for me. It's likely an issue with my side, or another addon i'm running as im sure a lot of people use this, and im not seeing a stream of similar issues. What is weird, is that it never gets past 0% progress of gathering info. With Librelec being it's own Just enough OS, i didnt expect it would be an internal permissions issue as others would be having it. Also wouldnt have through permissions on my remote side would be effecting the addon during the 'gatherinf info' stage of the process. That seemed weird. I'd be interested to know whether yours works fine on 11.0.6. (I update through the settings > libreelec > available updates > and select 11.0.6) |
|
OK so i thought i'd get these over to you as quickly as possible. As i was doing it i tried a few other combinations of settings. It seems that whenever i tick and enable backup of 'addon data' the issue happens. If i untick 'addon data' in the 'simple' selection field. Everything runs as expected! However, when i get the issue, it hangs LibreElec, so i can't actually upload my logs via the GUI. I have however managed to generate list of the addons that i have enabled. And theres more than i expected (mainly due to the large number of emulation/retroarch plugins that are enabled individually. :) So the logs below are actually from a sucessful backup! I did however monitor the logs using the web hosted log addon 'log viewer'... and then started a backup with 'addon data' enabled to try and capture a few log lines during the crash and i captured this: 2024-03-17 01:38:55.763 T:1748 info : ADDON: Dll Destroyed - SACD ISO support I'll try deleting that addon and trying again. Log uploaded after sucessful backupLogs: https://paste.libreelec.tv/together-impala.log List of Addons2023-02-16 18:11:05.175 T:900 info : CAddonMgr::FindAddons: audiodecoder.sacd v20.3.0.3 installed |
|
I've now removed the following addons that were showing errors in the log. XBMC LCDProc Trying again now with 'addon data' selected. |
|
OK so a bit of a dead end now. Ive removed the two addons above, but now i still hang when using 'addon data' selected. And theres nothing in the logs that i can see via the web viewer. Last entries. 2024-03-17 02:03:11.016 T:942 info : CActiveAESink::OpenSink - initialize sink |
|
I've now tried manually excluding various plugins through your advanced editor and after excluding, netflix, youtube, amazon and librespot (spotify) I now get a bit more infro that may be useful to you from the log. It still hangs in the unsual place but i get this: 2024-03-17 02:33:58.347 T:1819 error : EXCEPTION Thrown (PythonToCppException) : -->Python callback/script returned the following error<-- |
|
Thanks for gathering all this information. I didn't forget about this just been really busy traveling for work. Hope to dig into this next week. |
|
Just reporting the same behaviour on XBOX with Kodi 21.0 / backup 1.6.8. |
|
I tried to duplicate this a few times - to no avail. Without the exact point of the crash it's hard to say (like the stack trace from Python when it crashes) but it seems like you've narrowed it down to somewhere with the Sorry this is a pain. When testing I generally use a clean install of Kodi to ensure the addon will run as intended on a base system. 3rd party repos are often the big killer since they leave files open, hunting them down is a task for sure. |
|
Working on this some more I did finally see a version of this happening. It was when trying to restore from an SMB share. If the restore directory tree contains a lot of files and folders the initial file walk can take time which appears to be a timeout. In the restore I did it was minutes (4-5) of "gathering files". I think it could be a combination of the processor on the HTPC, network speed, and end storage device. I would speculate that this could also happen on smaller HTPCs like an RPi during the initial file walk for a backup as well. Going to do some debug logging and confirm some more. While it won't help the speed, making the progress dialog more responsive so you know it's working might be the end fix here. |
|
Hi rob, maybe it's worth on your test instance installing all the common plugins from the Kodi and libreelec repos and maybe the Amazon, netflix and YouTube plugin purely to closer replicate a lot of people's I installations? Ive recently updated to libreelec 12 and am still using the add-on with the exclusion for add-on data, so I'll try the add-on again today with add-on data included. For what it's worth my remote smb folder is a dedicated destination source with 1 or 2 large backup files in it so there shouldn't be much of a tree walk at the destination end whatsoever. Is there ment to be a timeout in the plugin during the gathering info stage after failing for say 5 mins minutes to finish that process etc? |
|
FYI: Tried re-adding "add-on data" after an upgrade from Libreelec 11 > v12. However the issue still exists. Do you need anything else from me at all? |
|
I haven't yet pushed my "fix" for this into the main Kodi repo so I wouldn't expect too much of a difference just yet. The patch won't really help the file gathering time any, just give you more information that something is actually happening. I've tried a number of tests with this and when using remote storage (dedicated NAS, cloud storage, etc) I can get some pretty consistent behavior when walking the tree. My best guess is that a combination of the target hardware, network connection, number of files, and source device processing speed are all in play. My best hope to mitigate this is to provide feedback to the user (progress bar or other such info) since making it go any faster isn't something I have control over. |
|
@robweber - Sorry i seemed to have missed this! I'll try again today and report back. I was assuming a stuck/open file was pbeing problematic from one of the addons. Is there any way of having an option potentially to turn on or off (users choice if they enable it) which queries kodi for a list of all currently running addons and then issues a bulk disable command across them all, performs the backup, and then reissues the enable command to them all afterwards? that may potentially help to alleviate individual addon troubleshooting going forward? maybe even present a generated list of all the known actively running addons for the user to select/deselect whether they want them stopped and started as part of the backup process? a kind of expert mode/custom config. I know of a few other backup/restore apps for various other platforms that do a similar thing to avoid active files from hanging the backup process? That would be something special! Just a thought... :) |
Running LibreElec on 11.0.6 (latest as of current date) on two RPI4B's, addon failing on both.
Add on using default settings as per the restore to 'default' settings button in the addon.
Addon hangs indefinitely at "Gathering File Info..." No timeout, no error.
Options configured on both are
Tried it with 'local location' set and 'remote location.'
Tried it with and without an underscore in the name.
Remote location: smb://192.168.1.125/mnt/disks/Unassigned_Backup
Cant actually get a working configuration at all out of it. Is there known issues with it right now before i start generating logs from both instances? And is it currently being maintained? (not being funny! Just asking...)
The text was updated successfully, but these errors were encountered: