237 replies to this topic

[WanWizard]

Remind me again on Saturday, I'm travelling atm.

[Pike_Bishop]

ok i will do it.

 

regards

Pike

[cmatte]

Interesting, I didn't spot this one, might be trying it out soon  

 

Just an heads up on this #p1109508 bug where swapon doesn't get activated correctly at boot from the 7.1 thread - with a possible solution tested and working fine.

[Pike_Bishop]

Hi WanWizard,

 

do you remember (i should remind you today);

https://forums.openp...dpost&p=1109828

 

 

regards

Pike

Edited by Pike_Bishop, 5 October 2019 - 17:42.

[WanWizard]

Thanks.

[Pike_Bishop]

thanks too for the commit;

https://github.com/O...38c1ddb5fbf1d30

 

 

regards

Pike

[cmatte]

Testing 7.2 on a vuduo4k. One bit noticed that might help

Fresh install, "software update" proposes 88 updates.

1. If updated with reboot, nothing happens but a reboot. At the next boot, all is as before. 
2. If updated with a further question, nothing happens at all.
3. If updated via ssh, only bootlogo is updated.
4. At next boot, again 88 updates shown, checking what's proposed shows there's an error with the command that returns the help, thus, I guess, "88" lines counted It seems the error comes from an unhandled space in the hdd mount.

[WanWizard]

Flash again.

 

It's a test image, it gets builds daily and may contain significant changes or fixes. This can happen if the versions of packages change (which can happen if we reset the build environment on the server).

[cmatte]

Hey, no blame intended, on my end, that was easily fixed by removing spaces from the disk label, which is mounted somewhere else anyway after the first boot, however I might not be the only one that happens to have spaces in the drive so just thought that would be useful for all to be fixed

[WanWizard]

I didn't feel blamed, I just explained why it could happen. I have no idea why a disk label would have anything to do with the updating process...

[cmatte]

Sure, let me expand 

You can install packages, e.g. picons, on any mounted drive, you'd get a choice or you can do it by terminal. Opkg would then create a database on the drive, specifically a var/lib/opkg/status file and a var/lib/opkg/info folder. Opkg is then able to retrieve what is/was installed in the drive, even right after a re-flash. In this case, the picons from the feed were installed on the hdd with a 7.1 image. When at first boot, an external hdd with a label like "My Hard Drive" is auto-mounted at "/media/My Hard Drive". 

At first boot with a brand new image, the update process attempts to load the databases on every drive, if any, and then seeks updates, in fact it was proposing updates for the picons right after the new flash of the 7.2 version. However, since the drive is mounted in a folder with spaces, not handled well by the script, it fails proposing "88" updates that are not there, but are only the help lines returned by opkg as it received a truncated command.

 

Hope it explains it. I've now changed the label to avoid all of this, however I'm sure this can be reproduced, I can do if that is helpful!

Edited by cmatte, 6 October 2019 - 14:05.

[WanWizard]

I understand that process, but if that is about picons, it should have an issue with 1 package, not with 88?

 

What script are you exactly refering to, that should be adapted to handle spaces in names?

[cmatte]

I can't say which script or code it is, or better, as I did not take a note of the screen content that was weirdly indented, I could not investigate more. However, basically it seems the GUI answers the user and considers how many packages are available to be updated based on the lines returned from some sort of $('opkg list-upgradable | wc -l') code, so it comes up with something like 88 available because opkg goes in error and lists the help lines, which then sum up to 88? Just a thought, based on the fact the last line on the screen was something like

 

>Hard Disk [something else...]

 

Edited by cmatte, 6 October 2019 - 16:03.

[WanWizard]

Ah, ok, you meant the update in the GUI. I'll pass it on...

[andy1]

Hi

 

The transparency adjustment does not work if you use teletext. Black background is impossible to achieve or adjust in the teletext menu.

I am using FBC tuners on my VU+ Ultimo.

[WanWizard]

What do you want exactly? You want the background to be transparent? Or not?

 

If I check it on my Duo 4K, the background is not transparent, and the transparency slider indeed doesn't seem to make any difference. But I can't recall ever having seen anything different.

[andy1]

What do you want exactly? You want the background to be transparent? Or not?

 

If I check it on my Duo 4K, the background is not transparent, and the transparency slider indeed doesn't seem to make any difference. But I can't recall ever having seen anything different.

I want the background to be black. As it was in previous versions years ago

Edited by andy1, 8 October 2019 - 16:35.

[WanWizard]

And now it is?

 

I have a non-transparent background in TuxTxt, the colour depends on what the broadcaster uses (in case they use the teletext 2.5 standard).

[littlesat]

Press menu in tuxtxt and there is should be a config

[andy1]

Press menu in tuxtxt and there is should be a config

..but this config menu does not work correctly. Try to adjust from transparent to black background. -Nothing happens