+1 on this, I’m also on a Pi 3
Hi’
In respect of the “20180103” image for rpi3, I did a fresh install today and suffered from the same app store install problem as previously reported. I engaged some verbose logging and took note of several entries concerning not being able to find files beneath of the directory /var/cache/apt/archives/partial. Upon taking a look it was discovered that the directory /var/cache/apt/archives/partial did not exist, so I created it manually, and then a subsequent app store install succeeded. This trick can hopefully be of help to others.
Best regards.
Thomas.
@ThomasLorenzen
Many thanks, that solves the installation issue for me.
R.
Edit - Sadly this only works one or twice!
That workaround worked once for me. Subsequent visits to the AppStore failed.
atm only apt-get from the commandline is working reliably, but it’s being worked on.
1 Like
Same for me also on Pi3
I wan´t install from App Store Samba, FTP and TV headend
Finished with error
Logs are here: http://paste.osmc.tv/guritizocu
After this I install over CLI:
sudo apt-get install smbclient
and
sudo apt-get install armv7-tvheadend-app-osmc
After this I have installed only TVheadend and directory /var/cache/apt/archives/partial already exist.
Then installation from App Store of SMB and FTP was succesfull.
Installed TV headend is version 4.2.4 and czech DVB-T2 multiplex still not found
Jan
1 Like
Did it exactly the same way as a workaround, out of the box doesn’t work!
cu
This issue should now be resolved:
You can expect an announcement of OSMC with Kodi v17.6 and Debian Stretch shortly.
Sam
1 Like
Hi Sam!
Addons like Quasar or YATP use Python’s os.uname()[4] to indentify the linux arch. This is commonly done when an addon has multiple binaries for different platforms but a same Python codebase. Since I’m testing this Debian Stretch implementation, those identifications fail on rpi2/3 giving “arm” and no “arm7”. I suspect that rpi1 also is not receiving “arm6” as a response. As a result of this, all addons using this kind of ids are trying to use the wrong binaries and going crazy because failing binaries are not very clear on KODI logs and sometimes are completely silent.
Way to reproduce over a Rpi2/3?
Install YATP https://github.com/romanvm/kodi.yatp and try to reproduce a Big Buck Bunny torrent from here http://bbb3d.renderfarming.net/download.html
It will fail. Even YATP will fail to start before trying to send a torrent file.
Now go to YATP settings and force arm7.
Try to reproduce the same torrent.
Now It will work because you’re forcing “arm7” as arch and no taking it from the OS automatic response.
This architecture identification was working OK on all your implementations prior this Debian Stretch.
If there’s something more needed to clarify the problem and i can help more, let me know.
Martin
Hello Martin,
This patch for OSMC helper routines was added for all platforms, but will only affect ARM platforms.
See
It initially resolves a problem with Netflix on Vero 4K. You can see which system call is overridden there.
Perhaps it should be changed to ‘armv7’, but it did look like the output of platform.machine() should have been arm when we compared it to Pi.
We’re patching in the context of platform.machine(), i.e.
>>> import platform
>>> platform.machine()
'aarch64'
It would be good if @gmc could check if changing arm to armv7 also worked with Netflix.
Sam
It would be good if @gmc could check if changing arm to armv7 also worked with Netflix.
Most addons needing to identify the machine architecture using os.uname() are doing it in that way because ‘platform’ didn’t resolve fine id architecture differences like those between ‘arm6’ and ‘arm7’ over 32bit userland, despite arm7 64bit capabilities. Correct me if I’m wrong but I also think that forcing os.uname() to just respond machine as ‘arm7’ will break this kind of addons forever on a rbp1 with OSMC.
As an example, you can check how this identification is done in libtorrentYATP def get_platform():
The advantage of YATP addon is that the libtorrent binaries are in a separate dependency module and has its own settings to force the arch manually if needed, but I know a lot of addons that doesn’t allow that, so not providing the right arch there will result in a problem to identify the correct binaries to use with no exit plan.
If there’s a way to respond to os.uname()[4] accordingly to every arch as this “non- documented-but-extensively-already-coded-conventions” expect, that will be the way to go. If not, expect some important addons breaking.
Sorry to bring this just today at the edge of Stretch release but I started testing the OSMC - Kodi 18 @gmc images just this past weekend, and that forced me to try Debian Stretch also. Prior that, all was working correctly.
I also have some unrelated and intermitent mounting problems using fstab, but i leave that to a future Help & Support post.
Martin
I’d recommend you checking what we’ve patched if you can.
We could make those helper routines specific to Vero 4K only for now. However do have plans to patch other system calls on other devices, hence the use of #ifdef. If we took things on a device by device basis it could become burdensome to maintain.
I have already asked @gmc to produce a future test build with an adjustment to this patch and he has agreed to do so. I’ll keep an eye on the results.
Let’s get those solved in another post. Hopefully they are not regressions of Stretch.
Thanks for the feedback,
Sam
Thanks Sam, I’ll keep an eye on it when I see new updates.
Do you suggest that i move my sources to stretch-devel or did I keep staying on main?
The Stretch update is now pushed.
I’d get off devel now unless you want to start getting the early parts of the January update through.
Thanks to all of those that tested these images.
The Debian Stretch update has now been released. See OSMC's December update is here with Debian Stretch and Kodi 17.6 - OSMC.
In the unlikely event you encounter an issue, it should be raised in a new thread.
Cheers
Sam