DM7080HD doesn't show all picons

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • DM7080HD doesn't show all picons

      Hi,

      I am using the NewNigma2 OE 2.5 from 01-01-2017 on my DM7080HD.
      I have installed my picons in /picons/piconHD and only some channels show the proper picons.
      All servicerefs starting with 1_0_1 are showing fine, but most HD channels where the serviceref starts with 1_0_16 or 1_0_19 don't show the picon.
      For all HD channels I have a picon image, but the name starts with 1_0_1, instead of 1_0_16 or 1_0_19.
      I remember with older NewNigma2 images, if the picon renderer couldn't find a picon for a servicref starting with 1_0_16 or 1_0_19, it would try to find one with the same name, but staring with 1_0_1.
      This doesn't seem to happen anymore and renaming hunderds of picons files manually isn't a solution.
      Also I didn't find the newnigma2-picon* packages in the feed :(

      Can the previous patch for the picon renderer be added to the OE 2.5 images?

      Thanks,

      Adri.
    • It would be nonsense to use 1_0_1 picons in case no 1_0_16 or 1_0_19 picon is around, as the SD versions of a channel don't have identical service references except the prefix.
    • Mausi schrieb:

      To install picons from feed you must install this

      feed.newnigma2.to/daily/oe2.5/…t20170102-r0.4_mipsel.deb

      For picons how dosn't show you must check the complete name of the file with the channel service reference.
      You will find that :
      Menu >> information >> Channel
      Picon Manager is already installed and available from the newnigma services menu.
      But I only see lots of picons for 19.2 east.
      For 23.5 and 28.2 hardly any picons are available and those are in the wrong format.
      Newnigma seems to require 100x60 picons and I tried other sizes before, but they don't show or scale properly.

      gutemine schrieb:

      It would be nonsense to use 1_0_1 picons in case no 1_0_16 or 1_0_19 picon is around, as the SD versions of a channel don't have identical service references except the prefix.
      I agree, but since NewNigma doesn't deliver proper picons for all sattelites, I am forced to use other third party ones.
      They don't seem to care about the proper serviceref prefix and always use 1_0_1. :(
      Older versions of NewNigma2 could cope with this, as the Picon Renderer tried to find the original servicref first and if it didn't find a picon, it would try again replacing the prefix with 1_0_1.
      Apparently, the current OE 2.5 based version no longer does this.
      I would appreciate it, if the old patch could be applied to the latest OE 2.5 image.
    • The solution seems to be simple, as there already is a similar check for servicrefs starting with 4097:
      See PiconResolver.py at line 16:

      Quellcode: PiconResolver.py

      1. if pngname == "" and x[0] == '4097':
      2. # lookup 1_* instead of 4097_*
      3. pngname = findPicon('1_'+'_'.join(x[1:10]))
      4. if pngname == "": # no picon for service found
      5. pngname = nameCache.get("default", "")
      6. if pngname == "": # no default yet in cache..
      7. pngname = findPicon("picon_default")
      8. if pngname != "":
      9. nameCache["default"] = pngname

      Another check could be easily added to check for x[2] being unequal to '1' (or perhaps unequal to '2' as OpenATV does it).

      Quellcode: PiconRender.py

      1. if pngname == "" and x[2] != '2':
      2. # lookup 1_0_1_* instead of 1_0_?_*
      3. pngname = findPicon('1_0_1_'+'_'.join(x[3:10]))
      Does this look alright?