Ok I didn’t read it.
We will wait the fix.
Next release?
@Ghost ?

HDMI in?
Maybe you don’t understand the problem....
Let’s wait @Ghost

Hi,
I think there is a bug in video driver in DM920.
To be able to use my external video processor I'm using autoresolution setted as screen attached.
Suppose to select a channel HD and autoresolution switched to 1080i mode.
Here there are two problems:
- it seems that video driver continues to switch between 1080i and 1080p . Dm920 is not able to get correctly the input resolution.
- If you select Mode Deinterlacer for interlacced contents to No you get no screen.

I attach enigma2.log.
Can you fix asap^
It is very annoying this problem!

Zitat von Ghost

What I can offer is an eDVBDB.getInstance (). SearchReference (int tsid, int onid, int sid, int dvbnamespace, int dvbnamespace_mask = -1) function ... so that you can then look over the mask to see if there is a matching channel

Nice and useful.
+1

It is enough.
Very clear. I'll do it when I have time and I'll test on my dm920.
Thanks

Ehm...
I must say that it is very strange that nobody sees the problem before
Meanwhile we can fix EPGImporter

@gutemine
If @Ghost decides that it is not time to change ServiceReference Class if you want I can give you an hand to fix EPGImporter plugin.
Let me know

It seems that in the experimental image the crond daemon is not enabled at startup.
It is very strange.
I had to start it with

> /usr/sbin/crond &

Why did you choose to not start crond at startup?
Do I have to create systemd script to start it?
Thanks

Ok bacause nobody replied I take some time this morning to see the code of PiconResolver.
It had two errors.
Solution here:

Solution

@Ghost
Ok I have some time to see you code (PiconResolver) and I found two errors.
I changed it in my dm920 and now all is working as described da Ghost.
Now all picons of dvb-t are shown without problem.
I attach new PiconResolver.py and patch.
Bye

PS: maybe epg problem of epgimport of dvb-t is equal to this.

As discussed in dm900/920 section it seems that there is a problem showing picon of dvb-t channels using default skin dreamOs.
The problem is related to namespace of dvb-t channels which is different from default EEEE0000.
Example: Rai 4 (see screenshot).

There is no picon in infobar while the picon is on fs:

root@dm920:/data/picon# ls -la 1_0_1_2187_4_13E_EEEE0000_0_0_0.png
-rw-r--r-- 1 root root 4375 Dec 11 22:00 1_0_1_2187_4_13E_EEEE0000_0_0_0.png

If I rename the file replacing EEEE0000 with EEEE0204 the picon in infobar is showed.

root@dm920:/data/picon# ls -la /usr/share/enigma2/picon*
lrwxrwxrwx 1 root root 11 Dec 11 17:38 /usr/share/enigma2/picon -> /data/picon
lrwxrwxrwx 1 root root 11 Dec 11 21:50 /usr/share/enigma2/picon_100x60 -> /data/picon
lrwxrwxrwx 1 root root 11 Dec 11 18:43 /usr/share/enigma2/picon_130x80 -> /data/picon
lrwxrwxrwx 1 root root 11 Dec 11 18:44 /usr/share/enigma2/picon_220x132 -> /data/picon
lrwxrwxrwx 1 root root 11 Dec 11 18:44 /usr/share/enigma2/picon_50x30 -> /data/picon
lrwxrwxrwx 1 root root 11 Dec 11 18:44 /usr/share/enigma2/picon_oled -> /data/picon

I attach enigma2.log created with

journalctl -f -u enigma2 > /data/enigma2.log

before changing channel.

@Ghost
There is some problem in picon resolver because after the author of MetrixStyleHD skin told me that the problem is not in the skin, I tried to select Default FHD which is one of DreamOs default skin and I have always the problem.
You have the test case in post 8.
The picon with namespace EEEE0000 is on filesystem but it is not show in infobar.
In share/enigma2 I have:

root@dm920:/data/picon# ls -la /usr/share/enigma2/picon*
lrwxrwxrwx 1 root root 11 Dec 11 17:38 /usr/share/enigma2/picon -> /data/picon
lrwxrwxrwx 1 root root 11 Dec 11 21:50 /usr/share/enigma2/picon_100x60 -> /data/picon
lrwxrwxrwx 1 root root 11 Dec 11 18:43 /usr/share/enigma2/picon_130x80 -> /data/picon
lrwxrwxrwx 1 root root 11 Dec 11 18:44 /usr/share/enigma2/picon_220x132 -> /data/picon
lrwxrwxrwx 1 root root 11 Dec 11 18:44 /usr/share/enigma2/picon_50x30 -> /data/picon
lrwxrwxrwx 1 root root 11 Dec 11 18:44 /usr/share/enigma2/picon_oled -> /data/picon

Let me know If you need something other information to solve the problem for dvb-t.
Thanks

Zitat von Ghost

Hi,

our PiconResolver always lookup for EEEE0000 picons...

So i think your skin have own Picon resolver / renderer which doesn't do this...

You can see this here at line 8,9.

cu

Alles anzeigen

@Ghost
How can I log what happens?
You are telling me that the problems I have in my dm920 are due to picon resolver and xmlimport engine.

Ok so for picons service ref is important and then the owners of dm920 have a problem with DTT because all picon packages use EEEE0000 ....
I'll try to use epgrefresh to see if I'll solve my epg problem.
I'll let you know.

No there is something not clear.
You and @gutemine are saying that EEEE0204 is only used for lamedb internally while for picon and epg is used EEEE0000.

Example: Rai 4 (see screenshot).

There is no picon in infobar while the picon is on fs:

root@dm920:/data/picon# ls -la 1_0_1_2187_4_13E_EEEE0000_0_0_0.png
-rw-r--r-- 1 root root 4375 Dec 11 22:00 1_0_1_2187_4_13E_EEEE0000_0_0_0.png

If I rename the file replacing EEEE0000 with EEEE0204 the picon in infobar is showed.
I suppose that I'm missing something.
Can you help me to understand?

PS: of course there is a sym link for picon:

root@dm920:/data/picon# ls -la /usr/share/enigma2/picon*
lrwxrwxrwx 1 root root 11 Dec 11 17:38 /usr/share/enigma2/picon -> /data/picon
lrwxrwxrwx 1 root root 11 Dec 11 21:50 /usr/share/enigma2/picon_100x60 -> /data/picon
lrwxrwxrwx 1 root root 11 Dec 11 18:43 /usr/share/enigma2/picon_130x80 -> /data/picon
lrwxrwxrwx 1 root root 11 Dec 11 18:44 /usr/share/enigma2/picon_220x132 -> /data/picon
lrwxrwxrwx 1 root root 11 Dec 11 18:44 /usr/share/enigma2/picon_50x30 -> /data/picon
lrwxrwxrwx 1 root root 11 Dec 11 18:44 /usr/share/enigma2/picon_oled -> /data/picon

@dhwz
Can you explain a little more?
I installed enigma2-plugin-extensions-epgimport - 1.0-r36.3: is it wrong?
If EEEE0000 is used internally for epg and Picons for dvb-t is a problem because the namespace is EEEE0204.
What am I missing?

I download epgimport from your post on oozoon board.
I supposed that it was the lastest version: am I wrong?
DVB-T has no normal epg data in italy: in most of case only two events for channel.
I tried epg refresh but it is not working well.
How can I solve my problem?
I'd like to use epg import.
Thanks

Hi,
I'm using the latest unstable experimental image in DM920 with twin dvb-s and twin dvb-c/t2.
I scan my italian dvb-t channels and all is working.
But... we have a problem: the namespace of terrestrial channels.
For example RAI 1 HD has service ref 1:0:1:218C:4:13E:EEEE0204:0:0:0 and you can see that it has namespace EEEE0204 whi is very strange (normal is EEEE0000).
Why?
The side effect is that epg import is not working on dm920.
Rytec EPG Team wrote:

"Try to find out why your receiver, makes these curious Namespaces (they are not normal). If you find the reason, correct that and you wil get EPG.
But, I have no idea where you have to look for this. (probably in the /etc/tuxbox/terrestrial.xml file)"

Where can I fix it?
Thanks

root@dm920:/data# ls -dlah /data/picon* /usr/share/enigma2/picon*
drwxr-xr-x 2 root root 120.0K Dec 11 18:17 /data/picon
lrwxrwxrwx 1 root root 11 Dec 11 17:38 /usr/share/enigma2/picon -> /data/picon
lrwxrwxrwx 1 root root 11 Dec 11 18:43 /usr/share/enigma2/picon_130x80 -> /data/picon
lrwxrwxrwx 1 root root 11 Dec 11 18:44 /usr/share/enigma2/picon_220x132 -> /data/picon
lrwxrwxrwx 1 root root 11 Dec 11 18:44 /usr/share/enigma2/picon_50x30 -> /data/picon
lrwxrwxrwx 1 root root 11 Dec 11 18:44 /usr/share/enigma2/picon_oled -> /data/picon

root@dm920:/data# ls -lah /data/picon/
drwxr-xr-x 2 root root 120.0K Dec 11 18:17 .
drwxr-xr-x 5 root root 4.0K Dec 11 18:42 ..
-rw-r--r-- 1 root root 11.4K Dec 11 18:17 1_0_19_1005_2DB4_13E_820000_0_0_0.png
-rw-r--r-- 1 root root 14.3K Dec 11 18:17 1_0_19_1015_1D4C_FBFF_820000_0_0_0.png
-rw-r--r-- 1 root root 15.4K Dec 11 18:17 1_0_19_1018_1D4C_FBFF_820000_0_0_0.png
-rw-r--r-- 1 root root 18.8K Dec 11 18:17 1_0_19_1020_1D4C_FBFF_820000_0_0_0.png
-rw-r--r-- 1 root root 15.1K Dec 11 18:17 1_0_19_1036_1D4C_FBFF_820000_0_0_0.png
-rw-r--r-- 1 root root 13.8K Dec 11 18:17 1_0_19_1037_1D4C_FBFF_820000_0_0_0.png
-rw-r--r-- 1 root root 14.8K Dec 11 18:17 1_0_19_1041_1D4C_FBFF_820000_0_0_0.png
-rw-r--r-- 1 root root 14.8K Dec 11 18:17 1_0_19_1042_1D4C_FBFF_820000_0_0_0.png
-rw-r--r-- 1 root root 12.7K Dec 11 18:17 1_0_19_104A_1D4C_FBFF_820000_0_0_0.png
-rw-r--r-- 1 root root 22.1K Dec 11 18:17 1_0_19_106A_2008_FBFF_820000_0_0_0.png
-rw-r--r-- 1 root root 21.9K Dec 11 18:17 1_0_19_106C_14B4_FBFF_820000_0_0_0.png
-rw-r--r-- 1 root root 22.0K Dec 11 18:17 1_0_19_106E_14B4_FBFF_820000_0_0_0.png
-rw-r--r-- 1 root root 11.8K Dec 11 18:17 1_0_19_1089_2008_FBFF_820000_0_0_0.png
-rw-r--r-- 1 root root 11.8K Dec 11 18:17 1_0_19_108A_2008_FBFF_820000_0_0_0.png
-rw-r--r-- 1 root root 11.8K Dec 11 18:17 1_0_19_108B_2008_FBFF_820000_0_0_0.png
-rw-r--r-- 1 root root 11.8K Dec 11 18:17 1_0_19_108F_2008_FBFF_820000_0_0_0.png
-rw-r--r-- 1 root root 11.6K Dec 11 18:17 1_0_19_1091_2198_FBFF_820000_0_0_0.png
-rw-r--r-- 1 root root 12.8K Dec 11 18:17 1_0_19_10CD_2DB4_13E_820000_0_0_0.png
-rw-r--r-- 1 root root 15.2K Dec 11 18:17 1_0_19_10EA_3E8_13E_820000_0_0_0.png
-rw-r--r-- 1 root root 14.1K Dec 11 18:17 1_0_19_10EB_3E8_13E_820000_0_0_0.png
-rw-r--r-- 1 root root 17.0K Dec 11 18:17 1_0_19_1131_2DB4_13E_820000_0_0_0.png
...............

The output is very long:

root@dm920:/data# ls -lah /data/picon/ | wc -l
1332

I inserted in /data/picon the files "picons-gioppygio-around-220x132-13-est_09.09.2017" + "picons-gioppygio-around-220x132-dtt-italia-20.10.2017".
I use dvb-s 13E + dvb-t Italy.
Bye

PS: other problem. I miss picon on lcd

Ok I left only picon in /data and then I create symlink under /usr/share/enigma2:

picon
picon_50x30
picon_220x132
picon_130x80

I have now two problems:
- no picon in list of channels (info bar sat yes);
- no picon in dvb-t (files are always in /data/picon)