Posts by Da Flex

OK, here is my next and final theory. People often believe that HDMI pass-through is a simple in-and-out process, but that's not right. Your AVR has to analyze incoming HDMI data to find relevant commands. My theory now is that RPi's volume change data are challenging for your AVR's processor. Probably so challenging that pass-through of video HDMI data will be dropped for the period of volume change.

However, my advice stays the same: get the extractor. Then your AVR just has to deal with audio data.

I'm not sure whether moving pictures really increase data rate on HDMI.

To check my theory, you could reduce the resolution for a test. This will definitely reduce HDMI data rate.

If you have audio pass-through activated, deactivate it for another test.

You probably found a way to reduce HDMI data rate by using this driver. Keep my HDMI audio extractor advice in mind when searching for a final solution.

Then you're right, and you only have on /off options. Other options are not part of the code for LE. Probably Raspbian has libraries that are not available on LE. You have to live with that behavior, or write your own demon.

Quote from Doodlenoodle

...it asks just wether I want the fan always on or not (here again I have to confirm with a “Y” for always on , otherwise the fan is set to off. So this means I can just turn it on (with about 6000rpm) or off.

Are you sure you understood this question right? Maybe you have to answer "N" / "No" for temporary and speed-controlled fan activation.

Maybe the fan is off at first, but at increasing heat it might start doing something.

Thanks for the detailed explanation. Probably the MCU does time measurement and triggers GPIO 17 (shutdown) for a short button press and GPIO 18 (power off) for a long button press. That keeps my theory alive. I think GPIO 17 has to be set to the default state after shutdown to switch the LED's red. I'll do some research what's the default state (low or high). Stay tuned.

Sorry to hear that. At least your cables are now conform to 4K.

Probably your former A-400 had a lower data rate, because it wasn't a 4K device. I think we now have isolated the AVR as the trouble maker when using higher data rates.

The only advice I can give is to order even more stuff.

The second HDMI port (HDMI-1) for audio doesn't work. Get an HDMI audio extractor to connect your AVR separately.

Sorry, according to your first code lines of your first post, GPIO 17 and GPIO 18 are exclusively used for the power button, not for LED's.

What you want is to switch the LED's from green to red after forced shutdown (long button press) and power off (short button press), right?

PS: Theory behind my question: Some GPIO pins have to be set back to default state to activate the red LED's. So long / short button press may lead to different results. If you know other device states that let the red LED's shine, let me know. The photo doesn't provide useful infos about the wiring.

Take care about pin numbering. You use GPIO 18, which is the 6'th pin at the outer side of the board, like here.

Unfortunately you haven't said anything about your LED wiring, so I can't tell you the right code.

Your power hat has red and green LED's, so I assume red is for off, and green for on.

That means, at least two pins must be in use for the LED's. Please tell me the pins, connected to the LED's.

PS: The data sheet doesn't tells the wiring, but the photo shows that only the first 12 pins (two rows) have connections to the power hat.

Chances are they use GPIO 17 and GPIO 18 for red and green LED's. Follow the wiring on the board to proof that theory.

Quote from rpistutters

Bump as the sample link will only remain active for another 7 days.

It's better to create a new thread, instead of permanently kidnapping and updating a solved one.

All your questions have been answered here.

Crazy.

Theory 2: Your add-on starts a server application, which needs some time to come up.

So try this autostart.sh:

#!/bin/sh

(
sleep 3
/usr/bin/sh /storage/tvmosaic/start2.sh
) &

If this works, you can play around with sleep time (sleep 2 for two seconds, sleep 1 for a second).

I had my moments with old hardware and Windows versions. It feels like a big waste of former lifetime, and still is a waste of time.

Theory: /etc/profile initializes environment variables for add-on's, but will only get executed when starting a shell session.

To include this process into your script, try:

#!/bin/sh

. /etc/profile
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${TVM_ROOT_DIR}/lib
export TVMOSAIC_ROOT_CONFIG_DIR=${TVM_ROOT_DIR}
${TVM_ROOT_DIR}/tvmosaic_server

Quote from John_T

Thanks for all the answers. Is there any possible (other) way except using an USB extension cable to a wireless operation of my RPI 4 at a 6 feet distance?

Get a Bluetooth adapter with an antenna and a Bluetooth keyboard. This should provide best signal range.

Unfortunately they are both USB-dongle-based, so you can't do anything to increase signal range.

My research says that your new WiFi adapter needs an RTL8812AU Linux driver, and milhouse currently includes that driver into LE.

Chances are, the driver hasn't been included into LE's major release, yet, but maybe it's already available as test build. Activate test builds (a.k.a. milhouse builds) this way:

1. go to Settings -> LibreELEC -> Updates
2. click Show Custom Channels
3. click - Custom Channel 1
4. insert http://milhouse.libreelec.tv/builds/master/RPi4 and click OK
5. click Update Channel
6. click Milhouse-9.80
7. click Available Versions
   
8. click the first entry at the list of test builds (not the highest number)
9. confirm the update

Hopefully this update will make your driver available, and the WiFi adapter should work without any further configuration.

Good luck!