18 replies to this topic

[Dream1975]

Hello,

 

Did a complete renewed setup and encountered one issue while also having some ideas.

 

Issue:

After a complete clean install cable scan didn’t work on a HD51. Knew I had it before also (see my previous post from 2012 link, in Dutch). In looking for this post I also found a more recent one (link). The HD51 has multiboot so did a test: Install clean image (with no autobackup), disable tuner A in the wizard (DVB-S) but leave tuner B (DVB-C/T) and configure it. Then do  scan (automatic/manual or cable scan doesn’t matter) and there it is depending on how you try you get “cablescan program not found ‘/usr/bin/tda1002x’!” or “search failed” in cable scan. Could be worth a deeper look into as it is a stubborn problem and thus even in a fresh install.

 

Ideas:

1. Autobackup: Make it identifiable by adding hostname to the folder (and maybe compress the backup in one file, off course also with the hostname identifier
2. Introduce configuring the Picons/epg location (to shares)

 

Elaboration:

 

Last week I've upgraded my home network and centralized everything. Pulled all the HDD/USB out of the enigma2 boxes and pointed everything to 2 mountpoints (a VHD share per box which takes over from the good old internal HDD/USB) and central storage location so all media can be reached/played/added by everyone/everything. It all works like a charm now but was very time consuming in configuring (especially finding out what where).

Ps. This is not to complain… absolutely not! I have been a happy user of PLi for about 20 years now and am so glad with all of you who have been maintaining it for all that time. It is in general often the case. A lot of these systems have a host system (Linux/Android/Windows) on top of that gui user software (Enigma2/Kodi/Android etc.) *** in the case of Linux on the PC even a desktop environment like Gnome/KDE in between*** which in turn can have addons/plugins/extentions/apps. Every layer needs config which is configured all around and even not always through the GUI for users but in config files and in rare cases in the code.

 For what I encounterd Pli specific (what I can now think back of out of my head):

1. Autobackup

The autobackup files don't have the box identification easily in it. So it was every time looking if I had the right one when centralized storing change things to try and import back. Solved it mostly by making a subdir per box but the disadvantage of that was the I needed to change folders all the time. It would be nicer if, for example, the hostname was in the (folder) name so they can all be at one place for editing making it instantly clear which one was from/for what box. Most Ideal would if the folder also would be compressed into one file instead of a folder aas autobackup does. Then all can be in one place making life easier in a centralized setup.

 

2. Data location (Picon/EPG)

When no HDD/USB present but only network shares the only option you get in the GUI for installing is internal memory with no manual override option (to select a share easy). I would like to change this to a share so only one box needs to import Picons while all the others can use them (nowadays network and storage are fast enough for it when configured the right way). Especially picons are quite large a download which is updated several times a week so why do it more than once.

The same goes for (non DVB) EPG import. Every box downloads it for itself completely understandable in the old times. But now there can be central storage thus making sense in one box downloading/updating it and the others using the same location without having to do anything.

As I know you host all EPG import data which costs you bandwidth every import I put extra investigation time in a “workaround” as I didn’t want to take advantage of by using more data is necessary by downloading the same several times. The workaround is now a script that copies/spreads the epg.dat and Picon folder to the others. But in general a path location setting in information sources would be nice.

 

Speaking of paths

Path configs are all over the place both in where to configure them (GUI vs editing config files), how to configure them and where they are stored (especially plugins). Some that come up in my head now regarding PLi:  Hostname/mountponts in network manager (stored in etc/enigma2), EPG in EPG import plugin as well as location epg.dat in settings-system-epg. Recording locations in setting-system-expert-recording locations. Etc. etc.

I absolutely do understand the reason. There is the Linux structure once thought but being handled in different ways varying from not exactly clear to where to put it, legacy or just making it easy and put is somewhere that is already being used for it. I found a lot of leftover (config) files of 20 years using and trying PLi with all kinds of leftovers (that are in no way problematic).

Finding this also leads me to applaud you all with how good your autobackup/update mechanism works as I never had to reconfigure freshly (not now also, but decided to do so in the change from the boxes going from mostly standalone to as much terminal as I can configure). In the info screen I have thousands of enigma restarts, which is probably nothing compared to some of the developers here, but this is only user use in 20 years.

 

It could be nice to have a settings screen where the most relevant path settings are all in one screen/config table. Plugin builders also can use this to pull path variable from it.

Just some ideas, maybe not good ones or workable but who knows just maybe some are �

 

 

[WanWizard]

After a complete clean install cable scan didn’t work on a HD51. Knew I had it before also (see my previous post from 2012 link, in Dutch). In looking for this post I also found a more recent one (link). The HD51 has multiboot so did a test: Install clean image (with no autobackup), disable tuner A in the wizard (DVB-S) but leave tuner B (DVB-C/T) and configure it. Then do  scan (automatic/manual or cable scan doesn’t matter) and there it is depending on how you try you get “cablescan program not found ‘/usr/bin/tda1002x’!” or “search failed” in cable scan. Could be worth a deeper look into as it is a stubborn problem and thus even in a fresh install.

 

This has been reported and commented on several times.

 

There are two ways of scanning DVB-C:

1. Using built-in scanning (automatic scan, manual scan)
2. Using the Cablescan plugin (which will automatically appear when installed and a DVB-C tuner is present)

The first option requires an external binary, specific for the tuner chipset, which must be supplied by the manufacturer in the BSP. Unfortunately, several have not bothered. tda1002x is the default if nothing could be found, which makes the message somewhat misleading.

 

The second option has a somewhat misleading name, as it doesn't (and can't) scan, it needs a frequency of the transponder that broadcasts the NIT table, and then uses the NIT table to tune the transponders defined in the table and enumerate the channels.

 

So the only thing we could do, is to display a better message than "cablescan program not found", but point users towards the CableScan menu option.

 

And for your remarks:

• The file /etc/hostname was excluded from the autobackup defaults on purpose, so you can use the backup to restore it on another box. If you want to include it, simply add it.
   
• There is no such thing as "epg location". EPG is stored in memory.
  The file epg.dat is a cache file, and is only needed and used when Enigma is restarted or put into standby, to avoid loosing your EPG data, since doing so releases all data in memory.
  It needs to be present when Enigma starts, so it must be stored locally. Once Enigma is started, it is not used anymore.
  Having said that, it is configurable in the EPG menu, nothing is stopping you from configuring /media/net/yournas/some/dir/epg.dat as location for the cache file.
   
• Nobody is stopping you replacing /picon by a symlink to /media/net/yournas/some/dir/picons.  If you hacked your setup to use a NAS for everything, adding this will be a no-brainer.
  In general is is a bad idea as picons get a lot of I/O so very low latency is massively important to not slow the UI down (which is a problem with network shares unless your network is really fast and stable).
  For the same reason it is not advisable to have picons on a HDD (SSD is not an issue), due to sleep, startup and spinup delays.

And finally to elaborate on a few of your other points:

• autobackup identification is on MAC address, and not on hostname. Which is always unique, unlike hostname in most cases (most users never change the default).
• Enigma has a built-in option to download EPG from another box, so there is no need to invent all sorts of complicated network based solutions, this works out of the box. All my boxes import channels and EPG when they come out of standby.
• Picons are under package management, so sharing them can lead to all sorts of issues, especially if you install them on one box, and try to update on another. And see my previous remarks.

[Dream1975]

Thank you for your reply. As I am away a few days for Easter I didn't have a change before to react, but when I am home later this week I'll do/try your suggestions. They make sense. For now have a nice Easter.

[Pr2]

Simply connect a USB stick on your STB and copy the picons to it, or if your box has a eMMC you can also use it.

 

About the EPG I also agree that it would be smart to have a unique download for several boxes. You cannot shared the epg.dat because it is saved when turning the box into standby, and having several boxes using the same epg.dat will corrupt it.

 

WanWizard solution to use the EPG from another box is working if you download the channel list and the EPG from another box.  But there is drawback on it, not everybody is using the same channel list on each boxes.

When you have a DVB-S2X capable box and a non DVB-S2X non compatible box as server you lose your DVB-S2X channels. Same applies if you have a combo box and the server is not. This turns into a real nightmare when I was testing this remote box solution because favorites and  DVB-S2X channels were disappearing. When there was a network isssue the channels were back, this turns me crazy before I realised that the channel list was coming from another box.

[WanWizard]

You can download and sync the EPG and not the channel list:

 

Attached Files

•  1_0_1_C482_811_2_11A0000_0_0_0_20240402123623.jpg   86.64KB   0 downloads

[WanWizard]

Ideally this code should be moved elsewhere, as technically it is not related to the fallback tuner at all...

[Dream1975]

There are two ways of scanning DVB-C:

1. Using built-in scanning (automatic scan, manual scan)
2. Using the Cablescan plugin (which will automatically appear when installed and a DVB-C tuner is present)

The first option requires an external binary, specific for the tuner chipset, which must be supplied by the manufacturer in the BSP. Unfortunately, several have not bothered. tda1002x is the default if nothing could be found, which makes the message somewhat misleading.

 

The second option has a somewhat misleading name, as it doesn't (and can't) scan, it needs a frequency of the transponder that broadcasts the NIT table, and then uses the NIT table to tune the transponders defined in the table and enumerate the channels.

 

 

 

My bad... as cable scan gave error "mislukt" I thought this one didn't work also after a fresh install (and it worked before because the binary was there from the past or something). But looking again the coax wasn't pressed in deep enough now it works again Sorry for the inconvenience.

 

And for your remarks:

• The file /etc/hostname was excluded from the autobackup defaults on purpose, so you can use the backup to restore it on another box. If you want to include it, simply add it.
   
• There is no such thing as "epg location". EPG is stored in memory.
  The file epg.dat is a cache file, and is only needed and used when Enigma is restarted or put into standby, to avoid loosing your EPG data, since doing so releases all data in memory.
  It needs to be present when Enigma starts, so it must be stored locally. Once Enigma is started, it is not used anymore.
  Having said that, it is configurable in the EPG menu, nothing is stopping you from configuring /media/net/yournas/some/dir/epg.dat as location for the cache file.
   
• Nobody is stopping you replacing /picon by a symlink to /media/net/yournas/some/dir/picons.  If you hacked your setup to use a NAS for everything, adding this will be a no-brainer.
  In general is is a bad idea as picons get a lot of I/O so very low latency is massively important to not slow the UI down (which is a problem with network shares unless your network is really fast and stable).
  For the same reason it is not advisable to have picons on a HDD (SSD is not an issue), due to sleep, startup and spinup delays.

And finally to elaborate on a few of your other points:

• autobackup identification is on MAC address, and not on hostname. Which is always unique, unlike hostname in most cases (most users never change the default).
• Enigma has a built-in option to download EPG from another box, so there is no need to invent all sorts of complicated network based solutions, this works out of the box. All my boxes import channels and EPG when they come out of standby.
• Picons are under package management, so sharing them can lead to all sorts of issues, especially if you install them on one box, and try to update on another. And see my previous remarks.

 

Clear and understood. Thank you for the explanation, makes it more clear to me how things work.

 

 

 

For the Picon part:

 

It is my understanding enigma2 now has only a few fixed locations where it looks for picons, namely ext4 mounted storage locations (as you can install picons on ext4 mounted usb, if the usb is fat32 then you won't get the option for using the usb when installing picons). However it makes no difference if they are installed as plugin on the box or not (if I put picons on a ext4 formatted usb in one box and put this usb in another it will also show the picons without having to do any install).

 

This gave me the idea for one box to install the picons on a share (which isn't presented in the options now, probably because it is not directly ext4 mounted) and if the standard "look for" could be configured in the other boxes (additional to ext4 mounted storage) only the box that installed them updates the picons (this is the only box where it is in the opkg packages list) and the others just "use" the picons in the folder because enigma always looks for them.

 

Off course the symlink is also an option, with the disadvantage of it not being in autobackup thus having to be reinstated a lot when flashing. This wouldn't be the case if the install location could be set besides only ext4 mounted locations for the main box (as well as the "look for" location on the other boxes).

 

But if I understand you correctly this isn't something easily changed/implemented by default and thus a manual symbolic link workaround hack would be the the only option. As they say in Dutch... It is no different then

[WanWizard]

As to picons:

 

Picon installations use symlinks to deal with the multiple-channels-2-one-image mapping, to avoid having to have multiple copies of the same image. This means the filesystem must support symlinks, which rules out FAT32.

The OpenPLi picon ipk installer enumerates all available (and suitable) local filesystems, and present them as location for installation.

 

From a technical point of view, it searches for these filesystems: 'ext4', 'ext3', 'ext2', 'reiser', 'reiser4', 'jffs2', 'ubifs', 'rootfs'. So not 'nfs' or 'cifs', which excludes network mounts.
Which is done because for standard users, mounts are made after Enigma starts (the mount manager), while the picon directory must be present before Enigma starts. So, yes, "het is niet anders" .

 

For picon display, Enigma does a search in the same locations in the same order, and uses the first one found. Which means that installing in multiple locations doesn't work either.

 

As to the symlink, that might indeed be an issue, as you can't add symlinks to the backup. But you can work around it using /usr/bin/enigma2_pre_start.sh, and do something like

if [ ! -L /picon ]; then
        rm -rf /picon
    fi
    ln -s /media/net/picon /picon
fi

and then add /usr/bin/enigma2_pre_start.sh to your autobackup.

[Dream1975]

WanWizard solution to use the EPG from another box is working if you download the channel list and the EPG from another box.  But there is drawback on it, not everybody is using the same channel list on each boxes.

When you have a DVB-S2X capable box and a non DVB-S2X non compatible box as server you lose your DVB-S2X channels. Same applies if you have a combo box and the server is not. This turns into a real nightmare when I was testing this remote box solution because favorites and  DVB-S2X channels were disappearing. When there was a network isssue the channels were back, this turns me crazy before I realised that the channel list was coming from another box.

I had the same experience. One box has DVB-S and the rest only DVB-C. So what I do now is use a HD2400 as "server" with 2x DVB-s and 2x DVB-C. All the other boxes use the cable scan list for normal viewing (with their own DVB-C tuners and fallback to the HD2400 if they record a DVB-C then they can still watch using one of the tuners in the HD2400, and I use the remote channel stream converter so all clients also have a bouquet with the sat channels in it which they can use that way.

[Dream1975]

As to picons:

 

Picon installations use symlinks to deal with the multiple-channels-2-one-image mapping, to avoid having to have multiple copies of the same image. This means the filesystem must support symlinks, which rules out FAT32.

The OpenPLi picon ipk installer enumerates all available (and suitable) local filesystems, and present them as location for installation.

 

From a technical point of view, it searches for these filesystems: 'ext4', 'ext3', 'ext2', 'reiser', 'reiser4', 'jffs2', 'ubifs', 'rootfs'. So not 'nfs' or 'cifs', which excludes network mounts.
Which is done because for standard users, mounts are made after Enigma starts (the mount manager), while the picon directory must be present before Enigma starts. So, yes, "het is niet anders" .

 

For picon display, Enigma does a search in the same locations in the same order, and uses the first one found. Which means that installing in multiple locations doesn't work either.

 

As to the symlink, that might indeed be an issue, as you can't add symlinks to the backup. But you can work around it using /usr/bin/enigma2_pre_start.sh, and do something like

if [ ! -L /picon ]; then
        rm -rf /picon
    fi
    ln -s /media/net/picon /picon
fi

and then add /usr/bin/enigma2_pre_start.sh to your autobackup.

Also clear to me know. Simplest is then to put a USB in each box for the picons which in turn all update them for themselves (or not use them). Very workable, but less ideal as I had in mind in order for the lengthy Picon update proces not being done more than once. However, I will try the suggested pre start sh (even if only just for expanding knowledge).

 

Thank you for your patience in enlightening me as technical noob who is trying/thinking of things without all necessary technical background knowledge (but in doing/trying is always learning and never tried is never a win is it ).

 

Again thank you for making me understand better and becoming slightly less noob

Edited by Dream1975, 2 April 2024 - 13:20.

[WanWizard]

I have a mix, some have only DVB-S, some also have DVB-T.

 

I use one of the boxes with both S and T to maintain my channel lists, and to collect (epgimport + epgrefresh) all EPG. All other boxes import from this box. Those that don't have DVB-T have fallback configured for DVB-T, so those remain working.

 

I don't have the recording limitation, I have a seperate box that does all recording and streaming, and which is programmed using the fallback timer and a hack to remotely access autotimer (which doesn't have fallback support as of now). All other boxes only have a single (configured) tuner, for watching only.

[WanWizard]

Again clear to me know. Simplest is then to put a USB in each box for the picons which in turn all update them for themselves (or not use them). Very workable, but less ideal as I had in mind in order for the lengthy Picon update proces not being done more than once.

 

Well,

 

Nobody is stopping you to use this pre-start script to create a local /picon directory, symlinked to a server mount, and then installing picons on one of the boxes. That will install the picons on the server, and automatically appear on other boxes using the same trick.

 

There are only three things to take into account

• add the enigma2_pre_start.sh script to the autobackup of all boxes so you don't lose it after a flash
• only update picons on the box you originally installed them (so don't install them on a second box, as opkg control files are local)
• take the delay of a network filesystem into account (there is quite a bit of I/O when Enigma reads them, and also when updating), so you need to test that

As to the latest point, I use local USB sticks because I have them anyway, for the autobackup. The speed difference between a slow USB2 stick and a fast USB3 stick (if the box has a USB3 port) is very noticable.

[Dream1975]

 

Again clear to me know. Simplest is then to put a USB in each box for the picons which in turn all update them for themselves (or not use them). Very workable, but less ideal as I had in mind in order for the lengthy Picon update proces not being done more than once.

 

Well,

 

Nobody is stopping you to use this pre-start script to create a local /picon directory, symlinked to a server mount, and then installing picons on one of the boxes. That will install the picons on the server, and automatically appear on other boxes using the same trick.

 

There are only three things to take into account

• add the enigma2_pre_start.sh script to the autobackup of all boxes so you don't lose it after a flash
• only update picons on the box you originally installed them (so don't install them on a second box, as opkg control files are local)
• take the delay of a network filesystem into account (there is quite a bit of I/O when Enigma reads them, and also when updating), so you need to test that

As to the latest point, I use local USB sticks because I have them anyway, for the autobackup. The speed difference between a slow USB2 stick and a fast USB3 stick (if the box has a USB3 port) is very noticable.

 

Great suggestion. Will play around with it this weekend. This would seem to give me the solution I was looking for.

[Dream1975]

Nobody is stopping you to use this pre-start script to create a local /picon directory, symlinked to a server mount, and then installing picons on one of the boxes. That will install the picons on the server, and automatically appear on other boxes using the same trick.

 

There are only three things to take into account

• add the enigma2_pre_start.sh script to the autobackup of all boxes so you don't lose it after a flash
• only update picons on the box you originally installed them (so don't install them on a second box, as opkg control files are local)
• take the delay of a network filesystem into account (there is quite a bit of I/O when Enigma reads them, and also when updating), so you need to test that

As to the latest point, I use local USB sticks because I have them anyway, for the autobackup. The speed difference between a slow USB2 stick and a fast USB3 stick (if the box has a USB3 port) is very noticable.

 

This doesn't work unfortunately. Creating the symlink does (also recreating it after flash). But installing to the symlink won't work (probably because of it trying to create symlinks for multiple-channels-2-one-image mapping ini the network share). I then tried to install Picons on a ext4 USB stick and copy the content to the network Picon share while having a symlink from root to this share (expecting it would/could read the copy) but no Picons are shown then.

 

Only remaining options are to install Picons on every box in root/usb or not use them it would seem. Not a big problem, it is what it is but I was hoping to te be able to find a way in using picons without multiple lengty update proceses for each box several times a week.

[WanWizard]

As said before, you need a medium that supports symlinks. That rules out CIFS, which you shouldn't use anyway, all NAS systems support NFS, which doesn't have that restriction.

 

edit:

 

just tested it:

root@ustym4kpro:/# cd /
root@ustym4kpro:/# mkdir /media/nas/picon
root@ustym4kpro:/# ln -s /media/nas/picon
root@ustym4kpro:/# opkg install enigma2-plugin-picons-snp-full.220x132-220x132.light.on.transparent

root@ustym4kpro:/# ls -l /picon/
lrwxrwxrwx    1 1024     users           14 Apr  2 20:45 0.png -> logos/cero.png
lrwxrwxrwx    1 1024     users           14 Apr  2 20:45 03itv.png -> logos/itv1.png
lrwxrwxrwx    1 1024     users           19 Apr  2 20:45 07bfbssport.png -> logos/bfbssport.png
lrwxrwxrwx    1 1024     users           35 Apr  2 20:45 100nlsongfestival.png -> logos/100procentnlsongefestival.png
lrwxrwxrwx    1 1024     users           13 Apr  2 20:45 10949vsid0x23.png -> logos/mtv.png
lrwxrwxrwx    1 1024     users           20 Apr  2 20:45 112.png -> logos/112ukraina.png
..

the only issue I have is that it takes absolute ages to install (it is connected to the NAS over wireless), and installing gives lots of errors as tar tries to restore root permissions when it unpacks the data archive, which is not allowed on my NAS.

Other than that, it works fine, if noticably slower loading channel lists.

Edited by WanWizard, 4 April 2024 - 11:19.

[Pr2]

 

Nobody is stopping you to use this pre-start script to create a local /picon directory, symlinked to a server mount, and then installing picons on one of the boxes. That will install the picons on the server, and automatically appear on other boxes using the same trick.

 

There are only three things to take into account

• add the enigma2_pre_start.sh script to the autobackup of all boxes so you don't lose it after a flash
• only update picons on the box you originally installed them (so don't install them on a second box, as opkg control files are local)
• take the delay of a network filesystem into account (there is quite a bit of I/O when Enigma reads them, and also when updating), so you need to test that

As to the latest point, I use local USB sticks because I have them anyway, for the autobackup. The speed difference between a slow USB2 stick and a fast USB3 stick (if the box has a USB3 port) is very noticable.

 

This doesn't work unfortunately. Creating the symlink does (also recreating it after flash). But installing to the symlink won't work (probably because of it trying to create symlinks for multiple-channels-2-one-image mapping ini the network share). I then tried to install Picons on a ext4 USB stick and copy the content to the network Picon share while having a symlink from root to this share (expecting it would/could read the copy) but no Picons are shown then.

 

Only remaining options are to install Picons on every box in root/usb or not use them it would seem. Not a big problem, it is what it is but I was hoping to te be able to find a way in using picons without multiple lengty update proceses for each box several times a week.

 

 

There is an autosearch for picon in OpenPLi it search in a given order (I don't it by heart).  You can of course place the picon on a USB stick and it is working.

Problem is that it search for a folder named picon in a specified list of folders, the first one it find it use it (either if it contains picon or not).

 

What you can do is:

find / -type d -name picon

Then delete the found picon folder that you not using.

Reboot the box and check the picon.

 

If they are still not displayed then you can create the symlink and reboot the box.

 

But if you change the picon location without rebooting it won't take effect, the search is only done at boot.

[WanWizard]

There is no real fixed order.

 

It starts with /usr/lib/enigma2/picon and /picon, and after that it enumerates are mount points with a compatible filesystem, and checks those in the order found.

[catastrofus]

Yep, just like it's working for me:

 

root@panoramix:~# find / -type d -name picon
/media/hdd/picon
root@panoramix:~# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 3.5G    295.2M      3.2G   8% /
devtmpfs                781.4M      4.0K    781.4M   0% /dev
tmpfs                    64.0K         0     64.0K   0% /media
tmpfs                   789.6M    280.0K    789.3M   0% /run
tmpfs                   789.6M    124.0K    789.4M   0% /var/volatile
/dev/sda1                 3.8G    657.3M      3.1G  17% /media/usb
192.168.1.119:/volume1/data
                          5.4T      3.3T      2.1T  61% /media/hdd
root@panoramix:~#

All the picons available on the synology, used by 2 ultimo4k's and 1 et10k.

[WanWizard]

Odd that that works, because I didn't think it would enumerate cifs and nfs filesystems.

 

If this does work, there's no need for a symlink, as you can just mount a picon share if you want?