S905X is a SoC and the drivers are there. You don't sell SoCs these days without providing Linux drivers or giving access to specifications.
Interesting. Where can I buy that package?
The common practice is that the manufacturer of a SoC delivers a developer board and an SDK. So the hardware API / drives are part of the SDK. It's hard to separate the hardware API / drivers from the SDK.
So my basic question is if it wouldn't make sense to clean house and find a (cheap) worldwide S905(x) partner for us users and support it, instead of linking dead or hard to get products.
I'm not an LE developer, but I'm reading here for a while. The main problem is getting driver source code and/or API documentation for the hardware. It's necessary for an LE build. S905x companies have no interest to give those data away, because that makes reproduction easier. That's why the Raspberry Pi became so successful - developers have hardware drivers access.
The new output looks much better. Yes, color space is independent of HDMI or DVI mode. All resolutions of the target device do appear. That's no bug, because the adapter transmits the complete abilities of the target device without filtering.
I was unable to send a developer a PM, because the function is blocked from his side. But you can still change thread title, and mark it as [BUG] to get developer attention. If that doesn't lead to any response, you can start a new thread in the "Bug Report" sub-forum.
Im looking at creating a fork of this and keeping a maintained version for libreelec on my GitHub.
I'll keep you posted with an update when I have it sorted.
It's basically about an autostart Python script. I wouldn't invested the time to permanently update a fork for that. Having an official add-on may be the most user friendly solution.
yes, cables etc are the same.
DVI>HDMI adapter limits resolution to 1080p so can't be workaround.
Thank you. I think HDMI connection is more tested by developers, compared to DVI. It really could be a bug, and a developer should have a look at this. If you want to help to fix it, you could deliver the output of "xrandr --verbose" when using the DVI -> HDMI adapter. That should show some comparable differences.
OK, you use exactly the same hardware (incl. DVI cable, which is sometimes a trouble maker), and RGB works on Windows 10, but doesn't works on LE, right? In that case it could be a DVI bug inside LE.
Using a DVI -> HDMI adapter sounds like the perfect workaround. Why don't you stay with it?
I bet it's a monitor problem. I just did a "xrandr --verbose" at my Ubuntu Linux, and the output shows all available resolutions of my connected monitor. Those entries appear after your last output lines ("non-desktop: 0, range: (0, 1)"). And I get an additional RGB entry:
Broadcast RGB: Automatic
supported: Automatic, Full, Limited 16:235So, I think your LE and graphic cards work alright, but your monitor doesn't give the necessary response to activate RGB mode.
Yes, the button shutdown behavior has been changed since LE 9.0. Try this as a workaround.
I had a look at your log file. Please check your storage device "sr0". It has I/O errors:
...
Mar 14 20:33:37 LibreELEC kernel: print_req_error: I/O error, dev sr0, sector 48912
Mar 14 20:33:37 LibreELEC kernel: sr 4:0:0:0: [sr0] tag#24 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
Mar 14 20:33:37 LibreELEC kernel: sr 4:0:0:0: [sr0] tag#24 Sense Key : 0x5 [current]
Mar 14 20:33:37 LibreELEC kernel: sr 4:0:0:0: [sr0] tag#24 ASC=0x64 ASCQ=0x0
Mar 14 20:33:37 LibreELEC kernel: sr 4:0:0:0: [sr0] tag#24 CDB: opcode=0x28 28 00 00 00 2f c4 00 00 01 00
Mar 14 20:33:37 LibreELEC kernel: print_req_error: I/O error, dev sr0, sector 48912
Mar 14 20:33:37 LibreELEC kernel: Buffer I/O error on dev sr0, logical block 12228, async page read
Mar 14 20:33:37 LibreELEC kernel: sr 4:0:0:0: [sr0] tag#26 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
Mar 14 20:33:37 LibreELEC kernel: sr 4:0:0:0: [sr0] tag#26 Sense Key : 0x5 [current]
Mar 14 20:33:37 LibreELEC kernel: sr 4:0:0:0: [sr0] tag#26 ASC=0x64 ASCQ=0x0
Mar 14 20:33:37 LibreELEC kernel: sr 4:0:0:0: [sr0] tag#26 CDB: opcode=0x28 28 00 00 00 2f c5 00 00 01 00
Mar 14 20:33:37 LibreELEC kernel: print_req_error: I/O error, dev sr0, sector 48916
...I think it's more about what you do with Nextcloud. There are always scenarios, when you will run out of memory when using Nextcloud. User chewitt describes the most performant solution, but if you have to stay with your current hardware, you can try to install an external swap partition (SSD) to expand the RAM. I don't suggest it, because it's probably slow.
Can somebody change the thread title please? It should be more content related, which makes it more usable for other interested people.
Before you create an add-on, and make in public for other people, it's best practice to start with a Python script.
I have found this tutorial, which describes basic Python RFID programming.
You have to install the "Raspberry Pi Tools" add-on from the LE repo, because you need programmatic access to the GPIO.
The major purpose of the Raspberry Pi is to make people start programming. Your project is doable, but you have to learn programming.
Part 1: Find a way to start a movie from command line by entering a command with a unique movie ID as argument. (maybe use MySQL)
Part 2: Write a LibreELEC add-on, which permanently reads your connected RFID reader, and sends a command (see part 1) when a card is near the reader.
Especially part 2 needs programming skills. To my knowledge, such an add-on doesn't exists.
Do you really want many hours of serious work just to have the luxury of a card-triggered movie player?
Unfortunately I get no sound at all although it must have done something as when selecting arc as my audio output my sub made a quick boom noise, usually the noise when you switch on a device connected to it.
You can try 2.0 channels on the LE audio settings (if not already selected). Maybe the extractor only works that way.
You could use an HDMI audio extractor: One HDMI input, one HDMI output, one analog audio output. Something like this.
The extractor should be connected to a second HDMI port on your TV, not on your RPi (wouldn't solve the out-of-sync).
If the second TV HDMI port works in path-through mode, the analog audio hopefully gets the right delay time to be in-sync.
I think it's not an LE problem. Both audio signals leave the RPi at the same time, but HDMI needs additional processing time on the target device. You maybe have a chance to grab analog in-sync audio from that target device.
I'm using a 3A PSU with a RPi3B+. 3A is a lot, and the lighting bolt never appears. Either you have a really bad PSU, which does not provide the advertised wattage. Or you have heavy consumers connected to your RPi.