Do you mean that the tagname.strip('.tar') works exactly like it should? If so, I highly doubt that, because tagname seems to be a string, and I doubt there’s a reason to remove characters from such a set from the start and end of that string. It very much seems like the idea is to remove a possible ‘.tar’ suffix from what goes into the tagstrip array, right? If that’s the idea then the code does not work like it should.
Also, I’ve suggested a way to actually circumvent the problem, so I’m not sure it’s been fixed “as best we could” if it could be fixed better.
Really? Why this hostility? I’m literally helping, fixing bugs.
You really clearly have enough developers if you’re threatening bugfixing messages to be just deleted. This is… very, very unlike any other open source project I’ve seen…
Yes tagname.strip('.tar') works exactly like it should. But because you didn’t read what I wrote already (you need to look code around and understand little more than just one line) you are saying it is wrong. Then let it be.
I would not say hostility but more frustration because you don’t read and/or understand what is written.
Anyway, now I’m really out. Have a nice day and sorry for a bad wording.
Sure this will be the “fix”. But you fix only releases since this change. What all about before out in the wild? Therefore a work around is need to cover this issue.
I doubt that, but I’d be super happy to be corrected. Why would you want to remove a’s, t’s, and r’s from the beginning and end of tagname? Like, if tagname was 'a.tag.bart' then strip('.tar') would output 'g.b'. Why would you want to do something like that? If you are right then I’d be very happy to hear the reasoning, and I would be very thankful to you.
I read everything in every message you wrote to me. I also read the surrounding source code. It’s looping through a bunch of filenames and adds some to tagstrip (with surrounding a’s, r’s, t’s, and dots removed), and to update_files.
There is no apparent reason for doing such a strip. None. What. So. Ever.
If you would do something so unclear in code, then at the very least you should add a comment saying why this weird thing is done.
And no, I did not say it’s wrong because I didn’t read the surrounding code. I said it’s wrong because it’s quite obvious what the intent is and it’s obvious that the code does not do what that intent is.
Yes, the workaround would be the one I proposed. Namely to make a release with a version that doesn’t end in a, t, or r. Then people could update to that first, and then from there update to anything else, because the code in that release is working correctly.
I couple of minor problems. Great to see this now in official stable release so well done guys. My box is a Ugoos X4Q Extra with the S905X4-J cpu. feeding through my Onkyo AVR with full Dolby Atmos installed. Running CE21 -ne with an extreme Ultra fast prepped bootable SD card and the uGoos X4 device tree. Runs superbly other than the 3 problems below. Also no longer need that small dovi.ko file added to the /storage folder for DV to work which it now does perfectly without needing this file
Problem 1 I have this problem sometimes but quite often that when I reboot or power up from the off state that I get the small square S906X4 AV1 loo but nothing further. Powering down and rebooting then brings up the normal boot to CoreELEC 21 -ne Is this a bug or some setting I need to change? It also happened with 20.5 when I switched to -ne from -ng happens with a fresh -ne install. When I upgraded to Omega 21 release it was pretty seamless and just migrated some nameless addons which took only about a minute and all working fine other than this sometimes annoying boot up problem.
Problem 2 Whilst I am here and this is most important, I also after pulling my hair out with instructions I found hard to follow, I finally installed the uGoos BT remote UR01_BLE.hwdb file simply using File Manager copy function (not sodding about with complex ssh which I cannot put up with nowadays and usually unnecessary), to the storage/.config/hwdb.d folder and rebooted. Still did not work until the penny dropped and I realised I had to pair the remote in the BT settings screen and using the appropriate two speaker up/down buttons together on the remote to put it into pairing mode. Yay. this then worked and finally I could easily use the uGoos remote
wonderfully as the IR remote.conf file was useless with this remote being so highly directional and PITA to use in IR mode.
However with dismay I found that each time I rebooted the box I had to go through the pairing again so this surely cannot be right?? There must be some way to make this automatically pair up on each reboot as it does booting into crap Android else it is useless and unusable. I tried renaming the remote hwdb file to 99-UR01_BLE.hwdb as het Readme suggested but this made no difference and cannot see what that can achieve if anything?? SO bottom line how do I set this up so it automatically pairs the uGoos BT remote at each and every boot up into CE 21 or is this a bug with Omega?
Problem 3 Finally the KODI repo addon Speedtester latest but quite old version, sticks after giving a ping result and will go no farther to show the needed down and up speeds as it used to. This was happening in CE20 too in both -ng and -ne. So does anyone know how to get this working as it is a useful addon.
Sorry for long post but had to give full details which I am sure others must be getting too with this popular uGoos X4Q box and setup and after upgrading to the -ne fork.
Portische, yes indeed but it needed along explanatory post and I did say sorry for that. I never included a log simply because I did not think a log would help here. The boot up problem I have reported by other friends and contacts with the uGoos X4Q box too who look to me for technical help, so as I had this problem too I assumed it was maybe a known bug. I can find and send a log if it will help but as I have to carry out a second power down reboot the log I think would be overwritten with the new successful boot ??
Astrotrain, how do you mean a full reset. I can try prepping a new install on an SD card and restoring my saved set up but I certainly do not want to go through making a brand new set up as that will take many many hours. With getting the repos and addons I need and setting up all my personal configurations. I was hoping there was some setting I needed to implement. Are you saying by default it should automatically pair at each boot up without any additional needed setting ?? This is the problem I need most to fix.
Hi everyone, what part of the forum do you think I can go to to try to find help with a chapter advance problem (Bug) that I’ve been having for a long time on CoreELEC?
I’m currently on Kodi 21.
There’s a new topic here on this issue, but it seems as if you are person 4 with this issue. For me, I had to do a complete system reset and start from scratch. Did you ever boot to Android using the CoreELEC menu, i.e Reboot from NAND?
Thanks freddy but I really do not use ssh these days. I used to but finding it too troublesome to play around with at my tender age of 78. Sure I do a lot of configuring KODI and setting up friends boxes with CoreELEC etc.
Have you got a url link for that zipped updated version of speedtester as I then can easily update my version from the install from zip function. I did similar with the thumbnail cache cleaner program which needed editing because of some changed python 3 command syntax.
Further to my original post with the three problems I can now state that Problem 2 is fixed. I got a friend of mine in Spain to install this BT remote .hwdb file to his X4Q Pro box with CE 21 -ng installed and after initially pairing his uGoos X4Q remote he had no problem with it auto pairing at each boot up. So as recommended by astrotrain I reburned my sd card with the new CE 21-ng downloaded file and restored my backup and bingo now after re pairing the remote it all works fine now with auto pairing on rebooting and even after power down and power on too. .
Only problem with the downloaded .hwdb file from the remote repository is that the menu button function does not work here or on my friend’s box also. So if anyone has a fixed UR01_BLE.hwdb file with the menu button working that they are willing to share it would much appreciated.
Finally I did need to reinstall that dovi.ko dolby vision enabling file again as the new reset system would once again not work for DV without it in the storage folder.
Hey Sholander that is exactly what I needed. I tried to install the one without the Matrix in the name as now on Omega and 2 generations on. But this one would not work with missing dependencies so assume this was for a version earlier than Matrix like Leia. So installed the Matrix version and bingo all is working again. Many thanks.
My only problem now is not having the menu button working on the BT remote but all else is fine and the needing to boot twice problem seems to have disappeared on its own for now at least.
