WanWizard

Oppassen met Redhat en btrfs, daar zit een berg politiek achter, die willen een eigen alternatief pushen, wat niet wil aanslaan bij het publiek. En dus hebben ze besloten kernel support in RHEL9 te stoppen. Dat heeft ze nogal wat klanten gekost.

Onze NAS clusters draaien nog EL8 met btrfs, en we zijn al bezig met het uitfaseren van RedHat. ZFSonLinux is een leuk project, maar haalt het niet tov de BSD variant, en is niet stabiel gebleken in onze clusters, dus we zijn overgestapt naar btrfs + drbd.

Maar goed, we dwalen inderdaad af .

Goed bezig...

The difference is 4 commits in oscam itself. 11801, 11802 and 11803 are about the oscam web interface, 11804 is a bug fix which is reverted in 11805, so maybe that is the issue.

OpenPLi develop always runs on the latest versions, which can be work in progress, untested, or unstable. If you can't live with that, or can't wait for the issue to be fixed upstream, don't run develop.

oscam-emu source was been updated with the latest oscam version an hour ago, so expect 11805 to be in develop on the next build.

Develop isn't pinned, it always builds from HEAD.

I've updated both the 8.3-release and 9.0-release feeds.

Plugins don't do ANYTHING related to the VPN itself.

If you have disconnects on the same box in specific circumstances, your configuration differs.

Ik heb in geen enkele box nog lokale opslag, alles gaat bij mij naar de NAS. De wifi is snel genoeg om op de NAS te kunnen navigeren (al moet je even wachten bij directories met heel veel files) en afspelen.

Als ik even test, de box heeft op dit moment

root@vusolo4k:~# iwlist wlan0 bitrate
wlan0     unknown bit-rate information.
          Current Bit Rate=130 Mb/s

( kan sneller maar hij hangt aan de verkeerde AP nu )

En dat levert als throughput dit op:

[wanwizard@alfred] $ iperf3 -c 172.19.12.52
Connecting to host 172.19.12.52, port 5201
[  5] local 172.19.15.52 port 48794 connected to 172.19.12.52 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  11.1 MBytes  93.2 Mbits/sec    0    243 KBytes       
[  5]   1.00-2.00   sec  11.9 MBytes  99.6 Mbits/sec    0    243 KBytes       
[  5]   2.00-3.00   sec  11.9 MBytes  99.6 Mbits/sec    0    243 KBytes       
[  5]   3.00-4.00   sec  11.1 MBytes  93.3 Mbits/sec    0    243 KBytes       
[  5]   4.00-5.00   sec  9.88 MBytes  82.8 Mbits/sec    0    243 KBytes       
[  5]   5.00-6.00   sec  12.1 MBytes   102 Mbits/sec    0    243 KBytes       
[  5]   6.00-7.00   sec  11.2 MBytes  94.4 Mbits/sec    0    243 KBytes       
[  5]   7.00-8.00   sec  10.9 MBytes  91.2 Mbits/sec    0    243 KBytes       
[  5]   8.00-9.00   sec  11.8 MBytes  98.6 Mbits/sec    0    243 KBytes       
[  5]   9.00-10.00  sec  10.2 MBytes  85.9 Mbits/sec    0    243 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   112 MBytes  94.0 Mbits/sec    0             sender
[  5]   0.00-10.04  sec   111 MBytes  92.9 Mbits/sec                  receiver

( daar zit enige vertraging in omdat ook mijn laptop aan de wireless hangt, ik heb geen ipref3 voor mijn NAS )

En belangrijker, niet significant sneller op dit moment dan 100Mbps bedraad.

Ik heb maar 1 box, een VU+ Duo 4K, waarmee ik alle opnames doe. Ik gebruik de fallback timer op elke box zodat ik wel op alle boxen via de EPG timers aan kan maken (die dan op de Duo 4K geplaatst worden). Deze box is de enige die wired aangesloten is hier, en heeft regelmatig 6 of meer parallele opnames lopen...

That smells like an ipk package installed manually.

Which means you have to be careful, as it is usually packages made for OE-A images that have their dependencies f'd up, since OE-A installs everything but the kitchen sink per default, so plugin makers don't care if they don't do things properly. And a lot of OE-A packages are not compatible with OpenPLi.

Also, the requirement for urllib2 indicates it is a plugin made for Python 2, which doesn't run on OpenPLi 9 and newer, as that requires Python 3.

We don't support that because it is instable and unreliable, as you have experienced.

Ik zal het even aanpassen voor de andere VU+ 4K modellen met kexec support.

Ok.

Om de kexec kernel te restoren:

• box booten in slot 0
• inloggen met ssh of telnet
• uitvoeren: opkg install vuplus-kexec --force-reinstall
• uitvoeren: dd if=/usr/bin/kernel_auto.bin of=/dev/mmcblk0p6
• uitvoeren: mv /usr/bin/STARTUP.cpio.gz /STARTUP.cpio.gz
• reboot

NB: voor meelezers: dit is UITSLUITEND voor de VU+ Duo 4K, niet voor andere modellen !

Als dit niet werkt, dan is plan B:

• backup maken van de directories linuxrootfs1, linuxrootfs2 en linuxrootfs3 middels tar -czvf, op externe opslag
  bv: tar -cvzf /media/hdd/linuxrootfs1.tar.gz /linuxrootfs1 (en zo ook voor 2 en 3)
• box opnieuw flashen via USB
• multiboot opnieuw installeren
• backup terugzetten in de root van slot 0
  bv: cd /; tar -xzvf /media/hdd/linuxrootfs1.tar.gz (en zo ook voor 2 en 3)
• slots moeten weer terug zijn na een reboot

NB: wellicht die backup eerst doen, alvorens plan A uit te voeren. Voor het geval de box daarna niet meer boot, dan kun je als nog Plan B gebruiken.

OpenMultiboot? Or the multiboot built into the image?

If the latter: there seems to be some VU+ BSP system package that isn't multiboot compatible, and breaks it when updating. We haven't found which package it is yet.

If slot 0 stil boots:

• telnet into it
• connect storage with 8GB+ space (depending on the box model)
• save the existing multibox slots:
  cd /media/<device>
  tar -czf linuxrootfs1.tar.gz /linuxrootfs1
  tar -czf linuxrootfs2.tar.gz /linuxrootfs2
  tar -czf linuxrootfs3.tar.gz /linuxrootfs3
• flash the box with a new image from USB (a new recovery)
• boot it, reactivate kexec multiboot again
• after the reboot, telnet into it
• restore the multiboot slots:
  cd /
  tar -xzf /media/<device>/linuxrootfs1
  tar -xzf /media/<device>/linuxrootfs2
  tar -xzf /media/<device>/linuxrootfs3
• restart, you should now be able to select and boot your multiboot slots again

Had the same problem last night...
 

Maar alleen als er lokaal geen tuner vrij is voor de gevraagde service reference.

De H8.2H heeft zowel S als C/T tuners, als deze de gevraagde service reference kunnen leveren zullen die eerst gebruikt worden.

Als de lokale tuners in de H8 niet gebruikt gaan worden, maar je wilt altijd fallback gebruiken, dan moet je zorgen dat de tuners zijn uitgeschakeld.

The relevant bit from the log:

Traceback (most recent call last):
  File "/usr/lib/enigma2/python/Components/ActionMap.py", line 57, in action
  File "/usr/lib/enigma2/python/StartEnigma.py", line 369, in powerup
    self.doAction(config.misc.hotkey.power.value)
  File "/usr/lib/enigma2/python/StartEnigma.py", line 394, in doAction
    menu_screen = self.session.openWithCallback(self.MenuClosed, MainMenu, x)
AttributeError: 'PowerKey' object has no attribute 'MenuClosed'
[ePyObject] (CallObject(<bound method ActionMap.action of <Components.ActionMap.ActionMap object at 0xb2e34988>>,('GlobalActions', 'power_up')) failed)

Die word standaard ingebakken voor je als deze ondersteund is (vuuno4kse, vuultimo4k, vuduo4k, vuduo4kse). De ipk heet "vuplus-hdmi-in-helper".