frakkin64 the images here Index of /testing/ have some tweaks to ffmpeg to improve (but not fix) seeking. It needs a proper coding community developer to take interest (or a large $$ sum to fund proffesional interest) to make progress.
Posts by chewitt
-
-
IIRC the default scraper changed from TVDB (v17) to TMDB (v18) due to TVDB switching to a commercial model and removing their user forums and other support methods. So the change will have nothing to do with RPi3 vs RPi4 but you probably switched hardware when switching to v18 and thus picked up the change at the same time. There are some tips in Add-on:TMDb TV Shows - Official Kodi Wiki to help with picking the correct show.
-
Kernel drivers should see that 120Hz modes are available on the HDMI connection and filter them out so that userspace applications cannot see or use them.
-
In the new video pipeline modes above 85Hz should be hidden since the hardware decoder(s) are not expected to work at those frame rates (bitrate is one variable but not the main one). It looks like there may be some scenarios where >85Hz rates are still visible, but now the Pi Foundation devs are aware I'd expect that to change in the near-term future. TL/DR; not supported.
-
-
They attempted to PR an Argon40 add-on to the Kodi repo; but it was Python2 and also LE specific so it was (correctly) rejected. I've since noticed an LE package in their GitHub repo; but it's a standalone package and it's not in a fork of our repo which is a rather odd approach (first time I've seen a dev get that wrong). The code is still Python2 and the package.mk had numerous other issues. I was kind of expecting them to reach out and ask Q's on how to submit to our repo .. but I've not noticed any emails. I'm sure they'll figure it out eventually.
-
PROJECT=RPi DEVICE=RPi ARCH=arm make image
^ that will get you an image, but it will run poorly because LE10 is not properly functional on non-RPi4 pi devices at this time, and even when we fix the main bug preventing an RPi2/3 release it will still run poorly on RPi0/1 devices because they don't have enough RAM for the new video pipeline; which is why we have no plans to release images for them anymore.
-
If you look in Kodi settings you will see SMB "client" settings. If you look in the LE settings add-on (also referred to in post #4) under services you will find the Samba "server" settings where there is definitely an "Auto-Share External Drives" option. You're looking at client settings.
-
Go into LE settings add-on > Services > Samba > Disable drive sharing - I forget the actual wording.
-
You might need to use a USB drive with external power rather than relying on a USB hub to power it correctly. I'll also point out that there is nothing wrong with booting from an SD card. So perhaps do a hybrid where /flash is on SD and /storage is on the USB drive.
-
USB mass storage boot - Raspberry Pi Documentation
RPi3B needs to have USB boot enabled in firmware first before it can boot from a USB device. Read and follow the links on ^ that page.
-
If your signature shows correctly and you have RPi3 .. we didn't realease LE 9.95.1 for RPi2/3 devices, hence there is no update. Read the blog post that discusses current status and why.
-
-
It's been noted and will be looked into.
-
What SD card (or image) are you booting from? .. it obviously has u-boot on the card (else it wouldn't boot) but it would be good to know. The fact you can boot something is a good start. What distro do you want it to run? (LE/CE, Armbian, etc.)
-
Seeking doesn't work .. I've been told something is missing from the hardware decoder (and the UAPIs for stateful decoders are still not finalised) but playback seems to work. I also have support for the Texas Instruments WiFi/BT in the newer Cubox-i version working and will push changes for that.
-
It's trying to accomoate the dumbfuckery of users who store videos, subs and other content inside zip/rar archive files. That ability needs to die in fire or be otherwise exorcised from the Kodi codebase - it's forever causing issues.
-
Put Kodi into debug mode and tail the logfile over SSH when you shutdown. Even if the connection is kicked we should maybe see something in the output that gives clues on where the problem lies - pastebin the log/output and share the URL here.