Dream1975

With me I get a crash when starting subssupport downloader from the feed, change the search query with the keyboard and then search. Has been so for a long time,

/usr/lib/enigma2/python/Plugins/Extensions/SubsSupport/seekers/utilities.py:192: FutureWarning: Possible nested set at position 1
Traceback (most recent call last):
  File "/usr/lib/enigma2/python/Components/ActionMap.py", line 72, in action
  File "/usr/lib/enigma2/python/Components/ConfigList.py", line 268, in keyNumberGlobal
  File "/usr/lib/enigma2/python/Components/ConfigList.py", line 43, in handleKey
  File "/usr/lib/enigma2/python/Plugins/Extensions/SubsSupport/subtitles.py", line 3301, in handleKey
TypeError: handleKey() takes 2 positional arguments but 3 were given
[ePyObject] (CallObject(<bound method NumberActionMap.action of <Components.ActionMap.NumberActionMap object at 0xaebd2ec8>>,('SetupActions', '2')) failed)

I also tried updating to the latest version with

wget http://raw.githubuse...in/installer.sh -O - | /bin/sh

But then I get

 * Solver encountered 1 problem(s):
 * Problem 1/1:
 *   - conflicting requests
 *   - nothing provides python3-rarfile needed by enigma2-plugin-extensions-subssupport-1.5.8-r9-py3.all
 *
 * Solution 1:
 *   - do not ask to install enigma2-plugin-extensions-subssupport-1.5.8-r9-py3.all
 

So unfortunately I can't test if the latest version does work (I tried with ATV in another slot and there it did).

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.

 

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.

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

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.