Replies: 16 comments 5 replies
-
|
Hi this is your work ;) because you have configured and enabled signal detection and this is probably some hardware problem. Next time it appears run |
Beta Was this translation helpful? Give feedback.
-
|
BTW
then jumps to decoding = 2ms
this suggests thermal throttling or an unstable power supply also causing throttling, but this is not conclusive. This is only clue, not evidence. maybe there will be something in dmesg. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks a lot for your answers! According to your message here is the dmesg output because I had the "frame too small error in the log) : https://pastebin.com/721HCf2W And the last log (without the signal detection, and without the auto-resume) : I don't know why, but for the moment (1 hour of test) I have no crash from the grabber despite the "frame too small error". That's quite surprising. The power supply of the RPI is a with 5v 3A (double usb, one for the RPI, the other for the fire TV 4k). And the hard drive connected to the RPI is spinning without a problem to play a 4k movie. The thermal throttling guess is interesting! Edit : the decoding seems now to be at 3ms |
Beta Was this translation helpful? Give feedback.
-
|
dmesg clearly shows the problem with the grabber, and for me its source is the power supply. in such configurations with an HDD, always use the original power supply + solid USB power cable, but under maximum load even this does not guarantee success because the RPi4 is not able to support two USB3.0 ports according to their maximum specifications (that's why the original power supply "cheats" and gives a slightly inflated voltage of 5.1V to slightly limit the occurrence of the problem in unusual configurations) and maintain some left power supply for itself. They fixed it in RPi5 with new PMic, still proper power supply is required. |
Beta Was this translation helpful? Give feedback.
-
|
well they didnt fix it completly in RPi5 but it's better. USB 3.0 port should provide 0.9 amps so 2*USB3.0 = 1.8Amps. And what about USB2.0 ports? |
Beta Was this translation helpful? Give feedback.
-
|
Whow i see. Thanks for your expertise! So if I use this to power externally the hard drive with a 5v power supply to help the RPI power delivery : https://amzn.eu/d/004nRswK And this original RPI power supply : https://amzn.eu/d/0iWDkcwX All should work fine ? For information, this is the power supply I am currently using to power the RPI and the Fire TV 4k (1A) : https://amzn.eu/d/00AkPhXb But if I unplug the fire TV, this should do the trick ? NB : For the moment, 2h of test, still no crash, and still at 3ms |
Beta Was this translation helpful? Give feedback.
-
|
You think I should try USB 2.0 ports? That's not gonna bottleneck the grabber? |
Beta Was this translation helpful? Give feedback.
-
|
It's hard for me to advise something and take responsibility for it here. such USB-Y cables are good, but they are usually used with the same device USB ports/power supply, but here the RPi power rail is a bottleneck and I don't know how it will behave if you connect one to the RPi with its own power supply and the other to another power supply. Connecting this grabber to USB2.0 is not recommended, but there is a chance that it will reduce power consumption, although it depends on the design of the device: usually they definitely limit transfer via USB: YUV->MJPEG. |
Beta Was this translation helpful? Give feedback.
-
|
maybe USB3.0 hub with active power supply? |
Beta Was this translation helpful? Give feedback.
-
|
I understand your explanation. But before ordering eventual parts, I try further combinations to try determine the origin of the issue. First test : I have been trying the same setup, but only the RPI connected to the 5v 3A power supply. It crashed, I don't know why. In just few minutes the refresh rate goes from 2 to 6ms, then the grabber stop (thermal throttling?) Log : https://pastebin.com/0gtjgid7 Second test : I disconnect the hard drive from the RPI. And the RPI is still the only one connected to the 5v 3A power supply. It crashes too, stable at 4ms. Log : https://pastebin.com/5x5SzxyP Third test : Only grabber connected in 2.0 USB. And the RPI is still the only one connected to the 5v 3A power supply. When the screen is black the leds are on (like backlight) and black border detection doesn't seems to work. But the overall seems not to crash. Log : https://pastebin.com/fcdUt3us Last test : Grabber on usb 2.0 and HDD on USB 3.0. All (fin the RPI) on the 5V 3A power supply. The overall seems working too, but the back borders are not working, same for the black leds (leds On when black) Log : https://pastebin.com/HJgXwTKk What do you think about that? Faulty grabber or power supply issue? I am hesitating. Earlier this day I was able to have no crash within 2 hour with the RPI, HDD, Grabber and Fire TV just on this same 5V 3A. That's kinda strange. |
Beta Was this translation helpful? Give feedback.
-
dmesg logs are missing when the problem occurs. These are the most interesting because the kernel drivers report problems there unless it is a critical failure and they cannot be read: but they are always available here. Something is throttling the system: either the temperature or the PMic, as it can also do this due to too much load. You can read the temperature on the HyperHDR website and the processor frequency from the command line. BTW, if you add up the costs of the RPi, various dedicated power supplies, the housing and your time, etc., it turns out that the RPi is not best solution for a media center with a connected HDD (maybe it would somehow work out with an energy-saving SSD or with HDD enclosure with independent power supply). Times are changing, now there are N100 with a rather trouble-free Intel USB3.2 bridge, faster CPU/GPU and 12V external power supplies that can easily handle the increased demand for current draw. RPi graphics system is archaic, even if we take RPi5 into account. |
Beta Was this translation helpful? Give feedback.
-
|
Hello awawa! By following your advice I just received the original RPI 5.1v 5A power supply to do tests. With this power supply and only the grabber connected (therefore without hard drive consumption) the grabber always ends up disconnecting. I'm starting to strongly suspect a faulty grabber. What do you think ? Log : https://pastebin.com/a3cKbe1S If you think this is the problem. Do you have a reliable grabber link that you know to recommend to me? Thank you again for your valuable help in this chaotic troubleshooting ! 🙏 |
Beta Was this translation helpful? Give feedback.
-
|
Have you measured your CPU temperature, load and frequency? RPi performance is still inconsistent. Is something running in the background? |
Beta Was this translation helpful? Give feedback.
-
-71 → Protocol Error. Maybe the Chinese "engineers" messed with the ms2130 firmware again, which has happened many times before. You can take a risk and upload the experimental firmware, it has been in testing for quite a long time, so it shouldn't make anything worse since this grabber doesn't work properly anyway. Backup the firmware first. |
Beta Was this translation helpful? Give feedback.
-
|
Another possibility is RPi4 eeprom. You are using Libreelec now. When did you last time (or ever) boot RPI OS to update it? Not sure if Libreelec is able to update it. There's no harm in checking it, RPi OS should automatically update it, but check its version from the CLI. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry to only come back to you now (I had to do some soldering on the APA102). I have just updated the EEPROM 2023 -> 2024. I am going to do some tests again to check if it is not caused by this! If necessary I would try to flash the new experimental firmware for the grabber (thanks to the Chinese "engineers" haha). The RPI is around 15 or 20% usage when a 4k movie is running, and does not exceed 80 degrees celcus (65 in idle). The installation is fresh, nothing is running in the background apart from hyperhdr! |
Beta Was this translation helpful? Give feedback.
-
|
I just flashed the experimental firmware. It's neither better nor worse haha. The crash is identical, and stable the rest of the time. Log : https://pastebin.com/qutXDBzg |
Beta Was this translation helpful? Give feedback.
-
|
As a reminder I had this grabber, to avoid : https://a.aliexpress.com/_EJPl9ur (shape C) Considering that this is a defective grabber, I plan to test these models:
Do you have any recommendations/links for reliable grabber ? |
Beta Was this translation helpful? Give feedback.
-
|
Elgato HD60x, it's working stable in my setup over the year or even more ;) But I doubt it's a grabber fault although it's possible. Around 80(begin of throttling)-85(full-throtling)C RPi4 starts to throttling, who knows whats happen to the communication over the bus with the external USB3.0 controller then (another flow of RPi4 compared to N100) |
Beta Was this translation helpful? Give feedback.
-
|
Set 640 x 480 @ 30 fps yuyv and enable quarter of frame mode in the grabber option to reduce the load |
Beta Was this translation helpful? Give feedback.
-
|
Hi! Last message (I think haha) to keep you informed of the progress! I received a new grabber (link above, in usb without loop). It works perfectly and without crash! I then added a passive heat sink box to improve the cooling of the RPI which went from 85° to about 50! Result: a reduction in latency which goes from 6ms to about 4, I don't see the relevance visually but in the logs it's nice to see, increased stability I suppose. Thanks again for the leads and your help! |
Beta Was this translation helpful? Give feedback.
-
Hello Awawa!
First of all I'd like to thank you for all the work you've put into this project, which is quite simply the most accomplished on the ambilight scene!
I'm back from the early days of ambilight on rapsberry, and I wanted to update my lighting infrastructure. I was using RPI3b with an internal grabber for about ten years, now I'm using RPI4b with an external grabber.
The information on my current equipment :
Everything seems to be working, only one small problem persists. After 15 - 30 minutes, the grabber disconnects unexpectedly, and I have to restart the RPI to get it working again. This problem can be solved by using the "auto resume" function, which restarts the grabber; the LEDs are only switched off for a few seconds, usually 5.
I can't find the cause of this problem. And the "auto resume" function causes the grabber to stop for a few seconds, which is slightly disturbing. I think the problem might be with the grabber, but I've probably missed something in the settings? Maybe something to force the grabber to stay connected non-stop?
Here's the log:
In this log the crash appeared at the end, and the option auto resume was not enabled.
I tried going through hyperion, but the problem is much worse, the grabber output is blurry, etc ...
Another persistent problem that seems to have been solved without explanation. When I changed the source from RPI to another source there was no problem, but when I returned to the RPI source the grabber gave me a green image with white text. To solve this problem I had to change sources several times between the RPI and a second device and the RPI image returned to normal. I don't know if this would help with the overall problem.
Thanks for your help!
Edit : I changed the grabber settings to full automatic, the problem persist. And with only the "auto resume" option checked it still stop just few seconds.
Beta Was this translation helpful? Give feedback.
All reactions