Fixed on le 10 with today's 20220916-591da77.
Thank you very much.
Fixed on le 10 with today's 20220916-591da77.
Thank you very much.
The le 11 nightly is already on the latest version, the one that was released today, and it has no issues with the json file.
It is le 10 nightly that I am talking about that has the problem in the log.
So, provided that one can wait bit longer, the "available versions" button does show the available images from the server and works like it should (downloads the image etc). I think that the delay is because the amount of images on the json file, which are now 10 compared to only 2 in the past.
This happens on le 11 nightly though. On le 10 nightly, nothing shows up, no matter how long I wait. I will check the log later for any info.
Here is the 8+MB log from le 10 nightly with a ton of errors! At least the json file is parsed correctly.
It was too big for pastebin I guess, so I took it from le and zipped it on my system to make it smaller than 1MB.
p.s. Please excuse any misclicks that made kodi parse the file twice.
A couple of days ago, I noticed that the main server's json file is back in place and lists all nightly images for 10 and 11
So I added the url to libreelec's settings > updates as a custom channel and libreelec 11 showed up under update channels, which means it does read the json file with success. However, when selecting available versions, nothing happens.
Tested on le 10 nightly on x64 and on le 11 nightly on rpi2, by selecting the relevant update channel on each installation.
Changing the server, which is removing a comment from somewhere or deleting a line completely so as to make it work, is a major update. Changing your name at the top of the script to add your info is a minor update.
Things that impact the general usability of the script should be considered major updates.
Can you please bump up the version number when you are doing major updates to the script, like the one for the server url? Thank you
Ok, put the padlock on this one. I am done with the nightly on the rpi and if I decide to start over, I will create a new one.
Right now I'd rather ask for help on the framedrops I see on le 10 and 11 on my x64 than this.
What you are asking me right now is to start fresh and waste even more time going through the things that I have already finished, just because kodi (or anything that kodi uses) has issues in those last 3 builds. We are talking about days of work and sorry I can not do that. I'd rather install something else on the rpi, e.g. armbian that caught my eye last month, to waste my time than start over.
Sadly, unlike x64, the rpi images do not provide a way for "live booting" with no configuration or addons. If they did, I would happily provide any sort of log.
I have to backup my stuff, then reset le and hope it pops the same errors, then post any logs and then restore my backup to continue with anything that I am doing. Rinse and repeat for every time there is a log needed.
I remind you that those 2 months that I am on nightly, I had to troubleshoot a corrupted filesystem, which was not an card issue but more of a "bad imaging on the card" issue and the wireless that still fails to connect every second or third day. Compared to the time I spend on what was important for me, those 2 issues took like 2/3rds of my time. And I am talking about the rpi only, leaving x64 aside.
Yes, I understand and respect your views about third party addons, but at this point I am not willing to waste any more of my time for le itself.
p.s. Aren't the above considered "full logs"?
3 updates (including today's) later and the error about hdmi-audio-codec is still there. I even removed the third party binary addon that I had, but nothing changed.
When it just happens at boot, e.g. now that it happened "only" 6 times, right before the system finishes its boot process, things are generally fine and I can connect via ssh and do stuff.
When it happens after all that, it fills dmesg and I must stop kodi so as to do anything because the lag is very annoying and the green led does not stop blinking! Earlier, it even disconnected me 10 seconds after stopping it and returning to the prompt!
I will keep updating it daily until Sunday. If the forementioned issue is still there, I will probably leave it aside and update it weekly or biweekly, just to be on track until the next alpha of kodi.
Ok, just don't complain about my third party addons and repos. They are not gonna be removed until I decide to stop using the nightly.
I did mention my third party addons and repos on early June (message 36 as seen above), but I got no reaction about them back then. Since they are the main reason I decided to use kodi 20 alphas and thus the nightly, I am not going to remove them, but neither I will ask support for anything about them.
And so far, the weird behavior of kodi while installing some of those third party addons has provided me with more knowledge than I expected.
Besides that, for me, the addons from the main repo are more troublesome than the third party ones, e.g. youtube and twitch with their api keys, speedtest which does not yet have a python 3.9 compatible version on the main repo, simple iptv (that I forgot I had it installed) that caused the recent issue etc.
I keep the nightly x64 installation without any addons, excluding confluence, but I update it twice a month now because I can not stand that wifi inconsistency. There is also a dlna bug (since v18 at least) I want to file to kodi's github because it has not yet been fixed. Plus an already open bug for the subtitles' font (by me) that I want to check its progress.
Leaving all the above aside, I removed pvr.iptvsimple from the kodi.failed folder and when I stopped kodi, it instantly renamed that folder back to .kodi! Is that normal?
I forgot to mention that I have not connected it to a tv yet, because I am still looking for a way that will allow me to work with minimal annoyances over ssh.
There you go.
This is the newest of 9 crash logs from everything that crashed today! There is also another crash log from July 13th. I know it is irrelevant to the above, but I am just mentioning it because there is a kodi_crash.log file which is a symlink to it.
# ls .kodi.FAILED/temp/ | grep 0725 kodi_crashlog_20220725073009.log kodi_crashlog_20220725073041.log kodi_crashlog_20220725073111.log kodi_crashlog_20220725073158.log kodi_crashlog_20220725073800.log kodi_crashlog_20220725073827.log kodi_crashlog_20220725073905.log kodi_crashlog_20220725073932.log kodi_crashlog_20220725074027.log # ls -l .kodi.FAILED/temp/kodi_crash.log lrwxrwxrwx 1 root root 32 Jul 13 14:16 .kodi.FAILED/temp/kodi_crash.log -> kodi_crashlog_20220713141609.log
Yea, this has happened to me again a couple of times before. It is just the first shock I get when I see the .kodi folder empty (or lacking the "structure" I spent HOURS to make)
As I said above, I do not connect it to a tv because wifi coverage on my tv's room is poor and, combined with the rpi's wifi poor reception, makes the whole thing a big test of patience
So, first things first. Do I stop kodi and replace the existing folder with the failed one (rm -r .kodi && mv .kodi.FAILED .kodi) and then move on with deleting the binary addons? Or do I connect it to the tv, just to check what happens? I am not really interested in booting to a stock kodi with no addons and with the estuary skin.
By that, do you mean kodi's log only, regardless if it reboots or crashes?
Shall I also follow this advice here and remove virtual.network-tools and virtual.system-tools?
I just did the first update after that annoying 20220723. It is 20220724 that contains the commit for the binary addons.
Once it booted, I tried to connect via ssh and it dropped my connection right before entering the password. I tried again and it then let me login with no issues.
However, the green led was blinking constantly, so I checked dmesg and the above error about hdmi-audio-codec had already appeared 6 times. After that, it stopped and the cec error took over and kept showing up until I issued a reboot.
After the reboot, the hdmi-audio-codec error filled dmesg again and after ~2 minutes, the system rebooted itself! It literally showed "the system is going down for a reboot now" and dropped my ssh session!
After that reboot, dmesg showed the error message for 6 times as it did above and then continuted with the one for cec.
Here is the journalctl output from that last boot.
And one from a new boot that the hdmi-audio-codec fills everything
It freaking rebooted itself while I was checking journalctl! It seems that unlike the cec error, the one about hdmi-audio-codec is more serious, because it causes the system to reboot after a while. So, consider the above pastes the outputs of a good boot and a bad boot respectively. Do I downgrade to the working build or do I open a bug report on github?
If you exclude addons like network or system tools, I do not think I have any other binary addons installed, including pvr.
I will check journalctl though... once I get tomorrow's update.
I had this idea a few minutes ago: I will stop kodi, so this error will stop and I will downgrade to the previous nightly, because it may solve this mess!
So I sshed to it and when I ran "systemctl stop kodi" it freaking REBOOTED! I connected again, checked dmesg again to see that both messages for cec timing out and the one above are still there. And they stopped when I stopped kodi. In fact, even the reboot command was done instantly with kodi stoppped.
If anyone has any idea for the above, please share. Yesterday's commits are way too many for me to understand which may have caused the issue. I am now waiting for it to downgrade to 20220721.
If you exclude some serious input lag after the first boot on 20220721 that made me mad, things are back to normal with it and only the cec timeout message shows up in dmesg.
Another bad day started for the rpi. After upgrading to today's 20220723 build, the green led did not stop blinking for like 15-20 minutes and commands like htop were not available again while .
However, this time it even decided to drop the wired (= could not connect wirelessly again) network connection and kill my putty session! It let me reconnect though.
Good thing I had btop handy to check what it is doing. The problem is, it was doing nothing really. All its 4 cores were at <5%, there was no io activity (unless btop fails to grab stats for the sd card, network activity was at 10kb/s and the only odd thing I noticed was some rm command that ran once and stopped. I could not check what it was deleting because its line was too short, but it finished doing so.
Finally, the above behavior is still observed after 3 boots: reboot > download the update and let it update > boot to that mess > reboot > boot again to that mess > reboot > boot to that mess for the third time. And I am now waiting for it to stop and issue a poweroff.
Also, at this last boot, there is this thing in dmesg that repeats many times
Normally cec would complain about not being able to connect, and although such messages did appear on the previous dmesg outputs along with the one above, now only the one above fills dmesg.