Posts by bluenote

In the end I realized I could check the serial #'s remotely, so pi's in service I pulled serials, then rotated through the ones sitting on the bench looking up their serials and matched them around with licenses. So, I didn't have to figure out how to allow software decoding. But ah, after that I did google some interesting patches to start_elf that might work if someone looks around a little, in case someone comes after me looking for this info.

Hey guys. I own a bunch of Pi's and several codec licenses, but over the years everything has been moved, repurposed, etc so I don't know which boards I have licenses for, don't feel like paying again considering patents are expired.

But, sw decoding doesn't seem to be enabled for mpeg2 by how the video acts (like there's just audio, roughly). How can I do this? I suspect this might be enough for me on an overclocked pi2.

Or alternatively, maybe there's a way to bypass licenses now that that would be legal where I am?

Thanks for advice.

Quote from mglae

Code

# modinfo 8812au|grep led
parm:           rtw_led_enable:Enable status LED (int)

You can try the module parameter if it is available on your RPI kernel.

Thanks, this allowed me to solve my problem. (But oddly, I don't seem to have this method being used on my primary libreelec, but whatever)
For anyone following in the future, this did it:

echo "options 8812au rtw_led_enable=0" > /storage/.config/modprobe.d/8812au.conf

Hey folks

Under raspbian, I successfully turn off the absolutely crazy-making blue LED on my 8811au usb wifi dongle using this driver and the methods given:

GitHub - aircrack-ng/rtl8812au: RTL8812AU/21AU and RTL8814AU driver with monitor mode and frame injection

Under libreelec, those methods don't seem to work. (I have no idea if that specific driver is being used, or maybe filenames aren't what I expect so ...)

However, it seems like past me found a way to do this on my primary libreelec installation. I cannot find any trace of the fix however.

But now I can't recreate the fix on another box I want to use, and, I'm afraid perhaps this will break in the future and I'll be treated to an extremely bright winking blue LED just under the TV. (Please don't tell me tape, this thing lights up the whole dongle in all directions).

Sometimes I feel like I'm the guy in memento with this terrible memory. Anyways, I figure if I solved it once, someone here must know how to?

thanks

EDIT: it does look like libreelec is using the same driver I am because I see the source files in /var/media/root/usr/src/rtl8812au-5.6.4.2

Quote from Mario77

Try to edit guisettings.xml

ssh

Code

systemctl stop kodi.service

edit line 321 in /storage/.kodi/userdata/guisettings.xml to 1920x1080@60hz

Code

<setting id="videoscreen.screenmode">0192001080060.00000pstd</setting>

ssh

Code

systemctl start kodi.service

Not tested but should work....take a guisettings.xml backup just in case.

Thank you so much for this. I spent hours screwing around with this and what you wrote here fixed my problem. Thanks.

Hey folks

So my inlaws have a pi2 that I maintain. They brought it to me for an update, and it won't detect/trigger my monitor or TV.

The funny thing is, I put the SD card into another pi 2 I have and that works fine.

Then I put another SD I had lying around with raspbian on it in the "problem" pi 2 and that drove the screen fine too.

I don't know wtf the commonality is here, please help there's obviously a hole in my knowledge.

Everything else is being kept exactly the same cables, etc.

thanks

Any knowledgeable folks want to chime in on the best way to capture an update not firing?

I've already manually upgraded. I'm happy to provide one next time, or even if I get a bit of time, try and recreate by installing a past version, but I need to know when the trigger for updating fires to know what I have to do to get you the portion of log you want.

That sounds sort of awkward, so I'll try and rephrase - is it enough to turn on debug logging, and just wait 5 minutes, or do I need to turn on debugging and then reboot, or go into the updates menu and set to manual then back to auto? What's preferred?

Thanks

Just had another come in stuck. Two things that I note -

This one, and probably the last one, had at least one addon that would not update because of a dead repo. And so, if there's anything in the triggers for how this operates waiting on kodi to report that it's up to date, or otherwise being blocked by an addon update process that's not actually running, that this might be a lead. I have definitely noticed kodi act a little strangely because of this factor before.

What's the correct way to replicate Libreelec ignoring an update? If I confirm updates set to auto, and sometimes switch to manual and set the channel, then go back to auto, and reboot, still nothing happens. At what point can I say "Ok, it should have updated under these circumstances." ?

No, auto update has not worked as expected for a long time. Arguing that "it works for me so it must be you" is counter productive. My environment isn't broken, and I maintain several pi's for family and they all never update anymore. While I'll grant that a) I'm not familiar with how libreelec manages (triggers, it seems to me) it's auto updates under the covers, and b) I understand dismissing the majority of unknowledgeable claims around here probably makes statistical sense, it's obvious to me at least that auto update isn't working the way it should be working. I have reasonably deep network experience professionally, the chances I am somehow causing this is by doing something really stupid is low. If I'm causing it, it's not something dumb relating to connectivity at the least.

I just got one back that was stuck on 8.0.2, and had to manually update even over the wire. I f I had to roughly guess, it hasn't been working generally for over a year. Could be longer.

Hope this twigs something for somebody.

Since I can access the SD it seems like I should be able to fix this, at least to be able to run a backup

Maybe you can suggest how to manually move the config over since I can copy files from the SD.

thanks

I'm reasonably sure I had a brownout situation/too high power draw that caused some corruption on my SD.

Now when I boot up, it gives me the 'filesystem corruption has been detected' blah blah 120 seconds warning.

I do let it try to recover, but it fails:

At the end of the recovery I get: "fsck.ext4 unable to set superblock flags on /dev/mmcblk0p2"

/dev/mmcblk0p2 WARNING Filesystem still has errors

Forced fsck failed. Your system is broken beyond repair.

Please re-install libreelec.

If I take the SD and connect it to my pi running arch linux, I'm able to mount it and view the directory structure.

I tried recovering the superblock with e2fsck -b (block) /dev/sdb2 , and it complains variously, and then booting does has the same result.

Can anyone suggest how else to fix this please?

thanks

Quote from milhouse

bluenote does the sysctl version work too, as outlined in this post? As this is likely to be the solution we implement.

Yes the sysctl method actually does seem to persist, so that should be the method I think.

Enabling this feature gives me a generic hotspot, but no internet access (from wired connection to the pi). Is there a way to do this out of the box?
Or, OP did you manage to configure this? (so it would appear, not forwarding between interfaces is my guess)

thanks for any suggestions, this will be a fantastic addition to my wired pi's.
[hr]
Just noting that I stumbled on a fix, and indeed, it is forwarding that is the problem.
kjosza explains here: thread-2236-post-43827.html#pid43827

echo 1 > /proc/sys/net/ipv4/ip_forward will temporarily fix it.

Quote from esfomeado

It works fine on the latest version of LibreELEC.

Thanks for the info!

This is the only adapter on sale right now, but without a return policy, so I'd like to know if this eventually got supported?

thanks

Thanks gents, much appreciated. I've added those changes and hopefully it'll work when it gets back to them.

Quote from lrusak

on RPi you can use config.txt

see, RPiconfig - eLinux.org

specifically,
hdmi_group=1
hdmi_mode=16

Hey thanks for responding.

I see the reason for hdmi_mode=16, but can you explain why hdmi_group 1 is better than hdmi_group 2?

thanks