Jump to content

alsc

Members
  • Posts

    15
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hello JMCC, I've been using the legacy kernel with Kodi and your multimedia solution and it's been working very well (apart from that reboot problem, but... well... I just sort of got used to it, and all). The issue I have is about lots of kernel error messages I'm getting. I sincerely don't remember if they already existed on the old kernel, although I believe not, since they are so many that would certainly got my attention, and I'm afraid it may be somehow corrupting data. At first I get these messages: [ 656.941038] zram: Decompression failed! err=-22, page=12547 [ 656.941050] zram: Decompression failed! err=-22, page=12547 [ 656.942641] zram: Decompression failed! err=-22, page=12616 [ 656.942656] zram: Decompression failed! err=-22, page=12616 [ 656.946072] zram: Decompression failed! err=-22, page=3109 [ 656.946370] zram: Decompression failed! err=-22, page=3109 [ 656.946378] zram: Decompression failed! err=-22, page=3109 They keep repeating to the point that there's nothing more on dmesg but them. Then, after a while I also get these messages: [283017.217836] EXT4-fs error (device zram0) in ext4_ext_truncate:4688: Filesystem failed CRC [283055.643907] EXT4-fs error (device zram0): ext4_find_extent:916: inode #22: comm sshd: pblk 1635 bad header/extent: extent tree corrupted - magic f30a, entries 69, max 340(340), depth 0(0) [283055.645528] EXT4-fs error (device zram0): ext4_ext_remove_space:2999: inode #22: comm sshd: pblk 1635 bad header/extent: extent tree corrupted - magic f30a, entries 69, max 340(340), depth 0(0) [283055.646503] EXT4-fs error (device zram0) in ext4_ext_truncate:4688: Filesystem failed CRC And finally it gets to the point that the disk gets unavailable and only works if a reboot. The messages refer to an external USB 3 disk and I know that it's working fine because if I switch to the LibreELEC sd card it never show these error messages. A appreciate any help you could give me. I believe it's somehow related to zram. I have the zram-tools package installed, but it's probably some issue on the kernel level.
  2. Hello there, Thank you for your suggestion. Based on what said I tried to pull out the hdmi cable as a test but I don't think I got the timing right, since it didn't work (I did it as soon as the reboot messages showed). Anyway it would be impractical on a daily usage, considering that most of times that I need to reboot the board I'm doing it remotely, so that I won't be able to physically disconnect anything. But it's at least something I can google about and try to find a little more.
  3. It worked! As soon as I rebooted after installing this new kernel it immediately worked! Thank you so very much for your invaluable help! After months of unsuccessful trials it's finally working. Is there a way these modifications you did (the kernel and the other patched packages) may become available by default on the RockPro64 Armbian image? It would make the Kodi part of your multimedia project even more complete and attractive to people with this specific board.
  4. Whatever you did now it's almost working! I mean, I got a different message to the first command: root@nostromo:/mnt/Dados# sudo cec-client -l libCEC version: 4.0.7, git revision: libcec-4.0.7+4-f9bb94a~dirty, compiled on 2020-07-09 22:37:00 by root@localhost on Linux 5.4.0-52-generic (aarch64), features: P8_USB, DRM, P8_detect, randr, Exynos, Linux, AOCEC Found devices: 1 device: 1 com port: Linux vendor id: 0000 product id: 0000 firmware version: 0 type: Linux So now when I start kodi-gbm it now shows the popup telling that the CEC Pulse8 Peripheral was detected and also there's the option to configure the CEC options (this is the very first time I'm able to use this option on a Armbian legacy kernel). And here goes the output of the second command: leonardocaldas@nostromo:~$ sudo cec-compliance -v -T -d0 CEC_ADAP_G_CAPS returned 0 (Success) cec-compliance SHA : not available CEC_ADAP_G_PHYS_ADDR returned 0 (Success) CEC_ADAP_G_LOG_ADDRS returned 0 (Success) Driver Info: Driver Name : dwhdmi-rockchip Adapter Name : dw_hdmi Capabilities : 0x0000000e Logical Addresses Transmit Passthrough Driver version : 4.4.213 Available Logical Addresses: 4 Physical Address : 1.0.0.0 Logical Address Mask : 0x0002 CEC Version : 1.4 Vendor ID : 0x001582 (Pulse-Eight) OSD Name : Logical Addresses : 1 (Allow Fallback to Unregistered) Logical Address : 1 (Recording Device 1) Primary Device Type : Record Logical Address Type : Record Compliance test for device /dev/cec0: The test results mean the following: OK Supported correctly by the device. OK (Not Supported) Not supported and not mandatory for the device. OK (Presumed) Presumably supported. Manually check to confirm. OK (Unexpected) Supported correctly but is not expected to be supported for this device. OK (Refused) Supported by the device, but was refused. FAIL Failed and was expected to be supported by this device. Find remote devices: MSG_POLL: Sequence: 1464 Tx Timestamp: 812.724s Length: 1 Status: Tx, Not Acknowledged (2), Max Retries MSG_POLL: Sequence: 1466 Tx Timestamp: 812.725s Length: 1 Status: Tx, Not Acknowledged (1), Max Retries MSG_POLL: Sequence: 1467 Tx Timestamp: 812.842s Length: 1 Status: Tx, Not Acknowledged (2), Max Retries MSG_POLL: Sequence: 1468 Tx Timestamp: 812.902s Length: 1 Status: Tx, Not Acknowledged (2), Max Retries MSG_POLL: Sequence: 1469 Tx Timestamp: 812.962s Length: 1 Status: Tx, Not Acknowledged (2), Max Retries MSG_POLL: Sequence: 1470 Tx Timestamp: 813.021s Length: 1 Status: Tx, Not Acknowledged (2), Max Retries MSG_POLL: Sequence: 1471 Tx Timestamp: 813.080s Length: 1 Status: Tx, Not Acknowledged (2), Max Retries MSG_POLL: Sequence: 1472 Tx Timestamp: 813.140s Length: 1 Status: Tx, Not Acknowledged (2), Max Retries MSG_POLL: Sequence: 1473 Tx Timestamp: 813.200s Length: 1 Status: Tx, Not Acknowledged (2), Max Retries MSG_POLL: Sequence: 1474 Tx Timestamp: 813.265s Length: 1 Status: Tx, Not Acknowledged (2), Max Retries MSG_POLL: Sequence: 1475 Tx Timestamp: 813.325s Length: 1 Status: Tx, Not Acknowledged (2), Max Retries MSG_POLL: Sequence: 1476 Tx Timestamp: 813.384s Length: 1 Status: Tx, Not Acknowledged (2), Max Retries MSG_POLL: Sequence: 1477 Tx Timestamp: 813.444s Length: 1 Status: Tx, Not Acknowledged (2), Max Retries MSG_POLL: Sequence: 1478 Tx Timestamp: 813.503s Length: 1 Status: Tx, Not Acknowledged (2), Max Retries MSG_POLL: Sequence: 1479 Tx Timestamp: 813.563s Length: 1 Status: Tx, Not Acknowledged (2), Max Retries Polling: OK Network topology: Total: 1, Succeeded: 1, Failed: 0, Warnings: 0 The only thing is that although Kodi detects the CEC structure, the remote still doesn't work. I've tried to make a couple of changes both using that command line which changes the hdmi physical address and trying to change them (both the hdmi physical address and port) on the Kodi config options. But it didn't work. In fact, in the case of Kodi no matter which physical address I fill as soon as I restart it comes back to what I imagine is the default (1000).
  5. Just to you to know, each time I install the packages you asked to (dpkg -i *.deb) I got the following message: ldconfig: /lib/aarch64-linux-gnu/libGL.so.1 is not a symbolic link And here you have it: root@nostromo:/home/leonardocaldas# cec-client -l libCEC version: 4.0.7, git revision: libcec-4.0.7+4-d6c8709~dirty, compiled on 2020-07-09 22:37:00 by root@localhost on Linux 5.4.0-52-generic (aarch64), features: P8_USB, DRM, P8_detect, randr, Exynos, Linux, AOCEC, 'i.MX6' cec-client: symbol lookup error: /lib/aarch64-linux-gnu/libcec.so.4: undefined symbol: _ZN3CEC27CTDA995xCECAdapterDetection11FindAdapterEv root@nostromo:/home/leonardocaldas# cec-compliance -v -T -d0 CEC_ADAP_G_CAPS returned 0 (Success) cec-compliance SHA : not available CEC_ADAP_G_PHYS_ADDR returned 0 (Success) CEC_ADAP_G_LOG_ADDRS returned 0 (Success) Driver Info: Driver Name : dwhdmi-rockchip Adapter Name : dw_hdmi Capabilities : 0x0000000e Logical Addresses Transmit Passthrough Driver version : 4.4.213 Available Logical Addresses: 4 Physical Address : 1.0.0.0 Logical Address Mask : 0x0010 CEC Version : 2.0 Vendor ID : 0x000c03 (HDMI) OSD Name : Playback Logical Addresses : 1 (Allow RC Passthrough) Logical Address : 4 (Playback Device 1) Primary Device Type : Playback Logical Address Type : Playback All Device Types : Playback RC TV Profile : None Device Features : None Compliance test for device /dev/cec0: The test results mean the following: OK Supported correctly by the device. OK (Not Supported) Not supported and not mandatory for the device. OK (Presumed) Presumably supported. Manually check to confirm. OK (Unexpected) Supported correctly but is not expected to be supported for this device. OK (Refused) Supported by the device, but was refused. FAIL Failed and was expected to be supported by this device. Find remote devices: MSG_POLL: Sequence: 181 Tx Timestamp: 29337.413s Length: 1 Status: Tx, Not Acknowledged (2), Max Retries MSG_POLL: Sequence: 182 Tx Timestamp: 29337.472s Length: 1 Status: Tx, Not Acknowledged (2), Max Retries MSG_POLL: Sequence: 183 Tx Timestamp: 29337.533s Length: 1 Status: Tx, Not Acknowledged (2), Max Retries MSG_POLL: Sequence: 184 Tx Timestamp: 29337.592s Length: 1 Status: Tx, Not Acknowledged (2), Max Retries MSG_POLL: Sequence: 185 Tx Timestamp: 29337.592s Length: 1 Status: Tx, Not Acknowledged (1), Max Retries MSG_POLL: Sequence: 186 Tx Timestamp: 29337.652s Length: 1 Status: Tx, Not Acknowledged (2), Max Retries MSG_POLL: Sequence: 187 Tx Timestamp: 29337.711s Length: 1 Status: Tx, Not Acknowledged (2), Max Retries MSG_POLL: Sequence: 188 Tx Timestamp: 29337.771s Length: 1 Status: Tx, Not Acknowledged (2), Max Retries MSG_POLL: Sequence: 189 Tx Timestamp: 29337.830s Length: 1 Status: Tx, Not Acknowledged (2), Max Retries MSG_POLL: Sequence: 190 Tx Timestamp: 29337.889s Length: 1 Status: Tx, Not Acknowledged (2), Max Retries MSG_POLL: Sequence: 191 Tx Timestamp: 29337.949s Length: 1 Status: Tx, Not Acknowledged (2), Max Retries MSG_POLL: Sequence: 192 Tx Timestamp: 29338.008s Length: 1 Status: Tx, Not Acknowledged (2), Max Retries MSG_POLL: Sequence: 193 Tx Timestamp: 29338.068s Length: 1 Status: Tx, Not Acknowledged (2), Max Retries MSG_POLL: Sequence: 194 Tx Timestamp: 29338.127s Length: 1 Status: Tx, Not Acknowledged (2), Max Retries MSG_POLL: Sequence: 195 Tx Timestamp: 29338.186s Length: 1 Status: Tx, Not Acknowledged (2), Max Retries Polling: OK Network topology: Total: 1, Succeeded: 1, Failed: 0, Warnings: 0 As you can see, there's an error in the output of the first command that wasn't happening with the first bunch of packages I installed a couple of hours ago. Edit: And by the way, now Kodi stopped working. I rebooted with no success...
  6. Hello, Followed your instructions, but it still doesn't work. Not sure what I should have expected, but what happens is that after doing what you told I both restarted just the Kodi proccess (systemctl restart Kodi-gbm) and then reboot the board itself, but there's no option on input peripheral to configure (which means that Kodi doesn't 'see' cec). Also the tv hdmi configurations shows no hdmi device connect (when I'm using LibreELEC I can see my device listed). As I said I'm accessing my board remotely via smartphone and it's kinda hard to copy / paste, etc, so Im attaching the output of each of your suggested commands in separate files (in the order you told to do). The weird part is that it doesn't seem to have error messages, which means that apparently it should be working... Thanks for taking the time to look into problem. 01_cec-ctl 02_cec-compliance_after 00_cec_compliance_before
  7. Sure. I'd already tried to install this cec-utils before, btw. And sorry I didn't post it with the correct code indentation. I'm using the smartphone and it's kind of hard to write... root@nostromo:~# ls -l /dev/cec* crw-rw---- 1 root video 249, 0 dez 17 19:17 /dev/cec0 root@nostromo:~# cec-client -l libCEC version: 4.0.4, compiled on Linux-4.9.0-8-arm64 ... , features: P8_USB, DRM, P8_detect, randr, Exynos, AOCEC Found devices: NONE
  8. Believe me, it would be perfect if you could find a solution. I tried to compile the kernel myself with cec as you suggested on the other thread (I still have the resulting generated deb files) but although it got installed without errors it made no difference. In fact a "uname -a" run after the installation and reboot showed what appeared to be the exact same kernel, as if no changes were made.. it was probably some mistake I made due to inexperience... Again, a working cec support on these RP64 would be amazing.
  9. In fact I'd never heard of these Internet controlled switches. I appreciate the suggestion and I'll Google it to see if I may adapt it to my needed. Thank you for your interest.
  10. I'm referring to this newer one (that I installed as soon as I saw JMCC's post), although I was never able to soft reboot using legacy kernels no matter which one I used (and I don't think the use of this tool, either the old or the new one, would have made any difference on this matter anyway).. In fact I had already given up trying to make a server with Kodi work with a legacy kernel. Mainly because of this reboot issue, but also because of the lack of HDMI-CEC support, that tried to enable on a customized kernel as described at the Armbian documentation, but wasn't successful. So I just gave up... Then I saw the new tool JMCC released and decided to give it another try, imagining that maybe any new kernel release would have solved the cec and the reboot stuff, but apparently they're still not working.
  11. Thank you very much for your work. I've been following your other thread once your tool's been one of the only ways I found to use Kodi on a RockPro64 in a server, without have to necessarily use LibreELEC. I really appreciate what you've been doing!
  12. Hello, I own a RockPro64 and I'm using Armbian Legacy Buster 4.4.213-rockchip64. Everything mostly works, although I've had a pretty annoying issue. Reboot just doesn't work. Every time I do a 'sudo reboot' (or any equivalent for that matter, as for example 'sudo shutdown -r now') it doesn't work. Although it apparently reboots, the TV monitor to which my box it's connected via HDMI lose connection and all, nothing actually happens. Both the red and the white leds of the RP64 turn on and keep on all time (instead of just one of them blinking, as expected) and then it will work only if I poweroff and on again, either by unplugging the power cable or pushing the reset button. That's pretty annoying, since for obvious reasons I can't remotely reboot the machine... I noticed that it only happens with the legacy kernels (I've tried Armbian and Ayufan, both have the exact same behavior). Current kernels work properly, but I really need, at least for now, keep using legacy (I'm trying to use the tool provided by the developer JMCC in order to use Kodi and it doesn't work on mainline so fat). I've googled for a while for this specifc issue and used the search from this forum but found nothing. Any help would be very appreciated.
  13. Hi there, Thank you for your prompt reply. May I bother you a little more and ask one or two more questions? When I was using LibreELEC I was able to use my TV remote control to interact with Kodi via HDMI-CEC. I had to configure nothing, and it worked out of the box. Now with Kodi I can't make it work (I installed Kore on my smartphone, but, welll.... it's far from ideal) . I've googled a little and noticed that not all kernels offer support to this feature. Is that the case here? If so, do you have any suggestion on what I could do in order to enable it? The other thing is about rebooting via software. I noticed that no matter the command I use ("sudo shutdown -r now", "sudo reboot", "sudo systemctl reboot") it kind of reboot (I can hear the attached disk power off and on again), the white led on the RP64 stops flashing and also power off but then they both (the white and the red leds) power on and nothing happens. It only works if I manually either disconnect the power supply or use the reset button. Is it anything I'm doing wrong, maybe? Again, thank you so much for your invaluable help.
  14. Hi there, This is my firs msg to this forum. First off I'd like to congratulate the devs on the superb work they've been doing. I own a RockPro64 for almost a year and always wanted to use it as both a small server (with a few services installed as for example FTP, NextCloud, etc) and as a media center connected to my TV via HDMI to run Kodi (so no need of a desktop... only Kodi and remote SSH access), but since hardware acceleration was a must, I'd never found a suitable option. So I've been using LibreELEC and installing things I need mostly using Docker (which is not that a good solution since I wanted a 'real' server). The thing is yesterday I found this topic and noticed the nice work you guys have been doing. I installed it (eMMC, which seems to be working smoothly so far), but I have a couple of questions I'd like to ask if possible. Since I don't need a desktop is there a way to boot automatically on Kodi, since it's all 'graphical' I'll need on this machine? I've seen a couple of old Kodi tutorials suggesting the creation of a systemd file, but I'm not sure if it's still valid to use with Armbian. Another option I saw here in this very forum, suggesting either placing kodi-gbm-wrapper in /etc/rc.local or disable the desktop and add "kodi" to my .bashrc (which I believe would be more suitable in my specific case). Which one do you suggest? And what would be the best way I could do that, considering that I just need boot on Kodi and remotely ssh the box? Another question is the kernel. I've read this whole thread and noticed that you optmized and hacked things deeply. I also noticed that the armbian-config tool has an option to 'freeze' the kernel. In order to keep using your optimizations I must freeze the kernel or it won't be necessary? And what about other updates? May I safely keep doing 'apt-get udate && apt-get upgrade' and just rebuilding your script? Another detail I noticed is about Kodi itself. As soon as I run it yesterday I saw a message warning about an update. I imagine I must not update, correct? The last question is about mainline kernels. I understand that you guys developed a specific solution to a specific scenario (in this case, a legacy kernel). Are there any plans to maybe develop a similar solution to mainline, though? Thank you very much for any help and keep up the good work. :)
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines