Posts by chewitt

    It's complaining that the memory region that you're trying to reserve/allocate is wrong. This might be something to do with 32-bit vs 64-bit kernels (different addressable ranges) or it might simply be that something else is using that range. Or it might simply be a case of different-on-Meson8. Some kernel archaeology is required: go hunting for the same/similar sections in ye olde 3.10 kernel device-tree files to see if you can see what parameters are being used.

    "ghost" media that disappeared in a HDD crash. I replace them whenever I can, but not actively looking for them. I know it's not the "cleanest" way to keep a list, but I haven't found a decent tool that would spit out a text list according to a given criteria. How can I extract said "ghost" media?

    Kodi Settings > Media > Clean Library should remove anything that's missing. IIRC there are Kodi add-ons that run this on a schedule or you can do it the old-school way and invoke a clean using the command line "kodi-send" tool from a cron task.

    The "viewed" state. Can this part of the database be restored over a fresh library scan?

    Just backup the DB files and guisettings.xml/sources.xml/passwords.xml files (and for bonus credit, the add-on settings files) then stop Kodi and restore them to the clean install before restarting Kodi .. and on restart it will migrate (update) the DB files to latest versions with all content and viewed state intact. The guisettings.xml file handles all the rest of Kodi GUI config and if you backed up the add-on settings you still need to reinstall the add-ons but nothing needs to be reconfigured from scratch.

    Learn how to do that ^ and Kodi updates from a clean install are trivial and take 5 minutes.

    The v4l2-request calls will fail because it's the wrong API for the silicon, but while ffmpeg falls back to software decoding you're still using the DRMPRIME path so you benefit from zero-copy in the output chain which is more efficient.

    To get the vdec driver to at least probe you'll need to transcribe the device-tree bits for canvas and vdec over from the meson-gx dtsi files (from fuzzy memory that's where bits live) and mark them as gxbb compatible. It will either work or not, depending on whether there are register differences. The hardware register and init sequences for this era of device are full of magic values and the vendor device trees c.2012 are borderline unreadable when you compare them to anything current (device-tree evolved somewhat).

    You need to initiate recovery boot (toothpick method etc.) else vendor u-boot will not look for LE boot scripts (which are different to CE boot scripts). The storage partition on the SD/USB is empty until first boot.

    stevie101 Some facts and guesswork:

    a) Amlogic requires the v4l2m2m stateful implementation not v4l2-request which is used with stateless silicon.

    b) The current (incomplete, staging) codec drivers were written for GXL but will work on GXBB and GXM too (and with notable issues on G12A and up) but while it is probable the current H264 (working) and perhaps MPEG1/2 (broken) codecs are compatible with Meson8 silicon, there is no platform ifdef plumbing for Meson8 in the "vdec" driver so none of the current codecs will be seen as compatible or available to V4L2.

    c) Firmware blobs are involved in stateful decoders so while I do not actually know, I also wouldn't be surpised to discover that some different firmware blobs are required for 32-bit arch or simply "older silicon" compatibility (newer blobs are needed for newer silicon and Amlogic is known-bad at backwards and forwards compat).

    1. Yes, the schema will be updated as part of the database migration

    2. Yes, create a clean install of LE12 on the RPi4 and stop Kodi and delete /storage/.kodi/userdata, then with the RPi3 powered on and connected to the network, SSH in and "scp -r /storage/.kodi/userdata [email protected]:/storage/.kodi" (change the IP for whatever the RPi4 is using) to recursively copy the essential Kodi config over to the RPi4 using scp, then when done, restart Kodi and the DB migration should start: run "tail -f /storage/.kodi/kodi.log" to see it happen. Adapt the same scp command to transfer any other bits of config that are important.

    NB: On the RPi4 you will need to reinstall repos and add-ons. We have intentionally not copied them due to the Python2 to Python3 change in LE10+ and the arm > aarch64 change in LE12. However their settings data was already copied. Everything else should be in the DB on the NAS. If you find something is missing you almost always stop Kodi, scp the data over, restart Kodi.

    I've recently been migrating Tvheadend documentation over to a new Docs/Wiki site https://docs.tvheadend.org and one of the text blocks I've moved talks about how multi-tuner setups on Raspberry Pi hardware can be troublesome. The issues flagged are power; as often you need to run tuners from a powered hub to ensure the current draw is handled instead of being directly connected to the Pi board, and bandwidth as this arrangement results in the tuners being connected to a single USB port. Then for extra credit it mentions that RPi 0/1/2/3/4 boards are sharing USB with Ethernet. RPi5 runs Ethernet from a proper PCI bus which should eliminate the latter issue, but the other issues are still possible.

    What happens with one tuner connected directly and other tuners connected via the hub? (experiment with different combinations)

    The last official WP2 image with support for the internal tuner is LE 9.0 and there's a community image for LE 9.2. The newer AMLGX image has no support for the tuner cards and S905 is from 2015 so I really wouldn't waste $50 on WP2 as an upgrade. If the WP1 is working for you as a DVB-C receiver I would continue to use it as a network tuner-only device and invest the $50 in a new client box or board. RPi5 is my go-to recommendation but probably needs a few more pennies than $50 saved.

    Hello, what about DVB addons?

    No change. There's been increasingly long delays between LE bumping to a new kernel and crazycat sources being available, which complicated our update cycles, and then upstream stopped maintaining the forward-porting mechanism required for dvb-latest. I'm not sure the team ever formally disussed abandoning all dvb-addon maintenance, but those add-ons incur a continual drip-feed of user complaints so over time we've exhausted the list of willing (and unwilling) volunteers. The best option is to find some hardware you can dedicate to an ancient LE or Ubuntu/Debian + modified kernel version and run cards/server end separate from a Kodi client running latest LE. And in the future, vote with your wallet and use hardware that either has upstream support or runs as a network appliance and avoid all driver shenanigans. Sorry for the lame/wrong answer /shrug