Jump to content


Photo

it913x USB DVB-T tuner reported as DVB-C after GUI restart

OpenPLi4 it913x Vu+ Duo2

  • Please log in to reply
68 replies to this topic

Re: it913x USB DVB-T tuner reported as DVB-C after GUI restart #41 athoik

  • PLi® Core member
  • 8,394 posts

+321
Excellent

Posted 18 January 2014 - 21:15

Did you try other open source images? (eg OE-A based images like OpenATV).


Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: it913x USB DVB-T tuner reported as DVB-C after GUI restart #42 macnuts

  • Senior Member
  • 420 posts

+14
Neutral

Posted 19 January 2014 - 16:01

No such problem on OpenATV :D . Does it bring us any closer to fix it on openpli (hopefully) :o ?



Re: it913x USB DVB-T tuner reported as DVB-C after GUI restart #43 athoik

  • PLi® Core member
  • 8,394 posts

+321
Excellent

Posted 19 January 2014 - 18:12

Why not? OE-A and OpenATV its open source...

 

Here are the changes in dvb.cpp (https://github.com/o...lib/dvb/dvb.cpp)

 

 

diff -Nuar openpli-enigma2/lib/dvb/dvb.cpp openatv-enigma2/lib/dvb/dvb.cpp
--- openpli-enigma2/lib/dvb/dvb.cpp     2014-01-19 18:49:48.323509581 +0200
+++ openatv-enigma2/lib/dvb/dvb.cpp     2014-01-19 18:50:26.117529512 +0200
@@ -2,6 +2,7 @@
 #include <linux/dvb/dmx.h>
 #include <linux/dvb/version.h>

+#include <lib/base/cfile.h>
 #include <lib/base/eerror.h>
 #include <lib/base/filepush.h>
 #include <lib/base/wrappers.h>
@@ -109,12 +110,24 @@
                m_boxtype = DM8000;
        else if (!strncmp(tmp, "dm800\n", rd))
                m_boxtype = DM800;
+       else if (!strncmp(tmp, "dm800hd\n", rd))
+               m_boxtype = DM800;
        else if (!strncmp(tmp, "dm500hd\n", rd))
                m_boxtype = DM500HD;
        else if (!strncmp(tmp, "dm800se\n", rd))
                m_boxtype = DM800SE;
        else if (!strncmp(tmp, "dm7020hd\n", rd))
                m_boxtype = DM7020HD;
+       else if (!strncmp(tmp, "Gigablue\n", rd))
+               m_boxtype = GIGABLUE;
+       else if (!strncmp(tmp, "ebox5000\n", rd))
+               m_boxtype = DM800;
+       else if (!strncmp(tmp, "ebox5100\n", rd))
+               m_boxtype = DM800;
+       else if (!strncmp(tmp, "eboxlumi\n", rd))
+               m_boxtype = DM800;
+       else if (!strncmp(tmp, "ebox7358\n", rd))
+               m_boxtype = DM800SE;
        else {
                eDebug("boxtype detection via /proc/stb/info not possible... use fallback via demux count!\n");
                if (m_demux.size() == 3)
@@ -271,27 +284,38 @@
        char filename[256];
        char name[128] = {0};
        int vtunerid = nr - 1;
+       char *line;
+       size_t line_size = 256;

        pumpThread = 0;

        int num_fe = 0;
-       while (1)
+
+       demuxFd = vtunerFd = pipeFd[0] = pipeFd[1] = -1;
+
+       /* we need to know exactly what frontend is internal or initialized! */
+       CFile f("/proc/bus/nim_sockets", "r");
+       if (!f)
        {
-               /*
-                * Some frontend devices might have been just created, if
-                * they are virtual (vtuner) frontends.
-                * In that case, we cannot be sure the devicenodes are available yet.
-                * So it is safer to scan for sys entries, than for device nodes
-                */
-               snprintf(filename, sizeof(filename), "/sys/class/dvb/dvb0.frontend%d", num_fe);
-               if (::access(filename, X_OK) < 0) break;
-               num_fe++;
+               eDebug("Cannot open /proc/bus/nim_sockets");
+               goto error;
        }
+
+       line = (char*) malloc(line_size);
+       while (getline(&line, &line_size, f) != -1)
+       {
+               int num_fe_tmp;
+               if (sscanf(line, "%*[ \t]Frontend_Device: %d", &num_fe_tmp) == 1)
+               {
+                       if (num_fe_tmp > num_fe)
+                               num_fe = num_fe_tmp;
+               }
+       }
+       free(line);
+       num_fe++;
        snprintf(filename, sizeof(filename), "/dev/dvb/adapter0/frontend%d", num_fe);
        virtualFrontendName = filename;

-       demuxFd = vtunerFd = pipeFd[0] = pipeFd[1] = -1;
-
        /* find the device name */
        snprintf(filename, sizeof(filename), "/sys/class/dvb/dvb%d.frontend0/device/product", nr);
        file = ::open(filename, O_RDONLY);

 

:) now its time to test...


Edited by athoik, 19 January 2014 - 18:12.

Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: it913x USB DVB-T tuner reported as DVB-C after GUI restart #44 athoik

  • PLi® Core member
  • 8,394 posts

+321
Excellent

Posted 19 January 2014 - 18:22

BTW, here is the commit [dvb] Fix vtuner frontend detection. (thanks to Skaman) https://github.com/o...36974ca70ab5d89


Edited by athoik, 19 January 2014 - 18:22.

Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: it913x USB DVB-T tuner reported as DVB-C after GUI restart #45 malakudi

  • PLi® Core member
  • 1,449 posts

+68
Good

Posted 19 January 2014 - 18:28

If I remember well this is a bug of the VU+ drivers not implementing correctly the vtuner interface. Xtrend/DMM/XP1000 boxes don't suffer from this issue. Most probably the OE-Alliance implemented yet another fix for broken drivers. On original VU+ images it works because they are using external usbtunerhelper which isn't restarted when enigma2 is restarted.


Edited by malakudi, 19 January 2014 - 18:29.


Re: it913x USB DVB-T tuner reported as DVB-C after GUI restart #46 macnuts

  • Senior Member
  • 420 posts

+14
Neutral

Posted 19 January 2014 - 18:36

@athoik:

Thank you I will test it but if it was a bug in vu+ driver implementation then I doubt that openpli team is going to apply box specific patch....

 

@malakudi:

is this specific to duo2 & solo2 drivers, or drivers for all vu+ boxes are affected? Where I can find a vtuner interface specification so I can (hopefully) point vu+ what they did wrong in their implementation?


Edited by macnuts, 19 January 2014 - 18:37.


Re: it913x USB DVB-T tuner reported as DVB-C after GUI restart #47 macnuts

  • Senior Member
  • 420 posts

+14
Neutral

Posted 20 January 2014 - 01:57

athoik, on 19 Jan 2014 - 18:21, said:

BTW, here is the commit [dvb] Fix vtuner frontend detection. (thanks to Skaman) https://github.com/o...36974ca70ab5d89

 

Athoik, after applying this patch tuners are reported correctly after enigma2 restart :D  :D  :D

 

Any chance that devs will merge it?



Re: it913x USB DVB-T tuner reported as DVB-C after GUI restart #48 malakudi

  • PLi® Core member
  • 1,449 posts

+68
Good

Posted 20 January 2014 - 11:00

Well, I am not a core developer but before merging such a patch we should understand what is the issue here. First part of the patch is not needed anyway, OpenPLI does not support Gigablue etc.

 

Why it works on first boot but not on enigma2 restart? It seems that either VU+ vtuner needs reinitialization after enigma2 restart and OpenPLI doesn't, or it doesn't need reinitialization and OpenPLI does it. Skaman's patch uses /proc/bus/nim_sockets to guess which tuners are native and which are external (USB). I still haven't  figured out why skaman's patch fixes the issue. Still trying to understand the code difference.



Re: it913x USB DVB-T tuner reported as DVB-C after GUI restart #49 macnuts

  • Senior Member
  • 420 posts

+14
Neutral

Posted 20 January 2014 - 11:15

@malakudi:

Look into the patch, it has noting about Gigablue. Athoik included head-to-head changes in dvb.cpp in one of his posts, not that patch itself.

 

Why it works on first boot but not on enigma2 restart?

 

See post http://openpli.org/f...ndpost&p=396614 and some that follow it.

 



Re: it913x USB DVB-T tuner reported as DVB-C after GUI restart #50 malakudi

  • PLi® Core member
  • 1,449 posts

+68
Good

Posted 20 January 2014 - 11:43

I've seen your post. The difference is that on other boxes (just tested with XP1000), when doing init 4 (enigma2 closes), /dev/dvb/adapter0/frontendX (where X > of internal tuners) is disappearing immediately. For VU+ (I have a Solo2), this doesn't happen as you have already found out. Why it doesn't happen? 

 

As for the gigablue part, I was mentioning this part of the patch, which is not needed.

+       else if (!strncmp(tmp, "Gigablue\n", rd))
+               m_boxtype = GIGABLUE;
+       else if (!strncmp(tmp, "ebox5000\n", rd))
+               m_boxtype = DM800;
+       else if (!strncmp(tmp, "ebox5100\n", rd))
+               m_boxtype = DM800;
+       else if (!strncmp(tmp, "eboxlumi\n", rd))
+               m_boxtype = DM800;
+       else if (!strncmp(tmp, "ebox7358\n", rd))
+               m_boxtype = DM800SE;

 

edit: Also, /sys/class/dvb/dvb0.frontendX is also disappearing after enigma2 is closed. Maybe VU's vtuner does not respond to a release ioctl? Haven't yet checked the code of the destructor. 


Edited by malakudi, 20 January 2014 - 11:52.


Re: it913x USB DVB-T tuner reported as DVB-C after GUI restart #51 malakudi

  • PLi® Core member
  • 1,449 posts

+68
Good

Posted 20 January 2014 - 11:59

Ok, seen the code, it seems when OpenPli does close(vtunerFd), driver of vtuner should release the kernel structures it has allocated. VU+ doesn't. We could add special handling there, or even better, inform VU+ to fix their driver.



Re: it913x USB DVB-T tuner reported as DVB-C after GUI restart #52 macnuts

  • Senior Member
  • 420 posts

+14
Neutral

Posted 20 January 2014 - 12:04

I do not know why tuners do not disappear immediately. But it looks like parsing nim_sockets is more reliable than checking /sys/class/dvb/dvb0.frontend%d (more reliable as it works for more boxes).

 

/sys/class/dvb/dvb0.frontend%d check replaced /dev/dvb/adapter%d/frontend%d check on 2012-04-11 (http://sourceforge.n...25c5a511278a706) as being more reliable. There is time for another change maybe? :)

 

About the gigablue part, I understand what you mean. What I mean is that it is not part of the patch I was referring to: https://github.com/o...36974ca70ab5d89



Re: it913x USB DVB-T tuner reported as DVB-C after GUI restart #53 macnuts

  • Senior Member
  • 420 posts

+14
Neutral

Posted 20 January 2014 - 12:16

---

It seems when OpenPli does close(vtunerFd), driver of vtuner should release the kernel structures it has allocated. VU+ doesn't.

---

Sorry if it is stupid question (I know nothing about dvb-sub drivers) but can it be that vtuner implementation expects some other handing for usb devices in dvb-usb-v2 environment? Vu+ images use dvb-usb-v2.



Re: it913x USB DVB-T tuner reported as DVB-C after GUI restart #54 malakudi

  • PLi® Core member
  • 1,449 posts

+68
Good

Posted 20 January 2014 - 12:37

It's not that they don't disappear immediately. They never disappear. VU+'s vtuner driver does not respond to the close ioctl triggered by close(vtunerFd). To me this is something that needs to be addressed in the VU+ drivers, especially since it works on all other boxes.



Re: it913x USB DVB-T tuner reported as DVB-C after GUI restart #55 malakudi

  • PLi® Core member
  • 1,449 posts

+68
Good

Posted 20 January 2014 - 12:40

This has nothing to do with the dvb-usb or dvb-usb-v2 stack. As it seems, it is the implementation of the vtuner interface - lacking support for releasing the resources on close request. Of course the work around could be implemented, but since we now know exactly what the issue is, maybe someone could inform VU about it.


Edited by malakudi, 20 January 2014 - 13:24.


Re: it913x USB DVB-T tuner reported as DVB-C after GUI restart #56 pieterg

  • PLi® Core member
  • 32,766 posts

+245
Excellent

Posted 20 January 2014 - 12:41

indeed, it needs to be fixed where it is broken



Re: it913x USB DVB-T tuner reported as DVB-C after GUI restart #57 malakudi

  • PLi® Core member
  • 1,449 posts

+68
Good

Posted 20 January 2014 - 12:42

@pieterg: Have I figure out the behaviour correctly? close(vtunerFd) is responsible for releasing /sys/class/dvb/dvb0.frontendX, yes?


Edited by malakudi, 20 January 2014 - 12:43.


Re: it913x USB DVB-T tuner reported as DVB-C after GUI restart #58 macnuts

  • Senior Member
  • 420 posts

+14
Neutral

Posted 20 January 2014 - 14:48

Before I report a vtuner bug to vu+ I would like someone with dvb & vtuner knowledge to confirm or correct the following (based on current findings):

 

vtuner vu+ implementation does not clean up itself on enigma2 close, causing problems with restart.

caX entries are not cleaned up (removed form file system) - per usb stick

frontendX entries are not cleaned up - per usb tuner.

 

As example of leftovers: usb stick with two dvb-t tuners (usb dvb-t dual tuner):

/sys/devices/virtual/dvb/dvb0.ca8
/sys/devices/virtual/dvb/dvb0.frontend3
/sys/devices/virtual/dvb/dvb0.frontend4

/sys/class/dvb/dvb0.ca8
/sys/class/dvb/dvb0.frontend3
/sys/class/dvb/dvb0.frontend4

dev/dvb/adapter0/ca8
dev/dvb/adapter0/frontend3
dev/dvb/adapter0/frontend4



Re: it913x USB DVB-T tuner reported as DVB-C after GUI restart #59 malakudi

  • PLi® Core member
  • 1,449 posts

+68
Good

Posted 20 January 2014 - 15:40

Better replace "enigma2 close" with "when close is called to the vtuner I/O handle". /dev/dvb/adapter references will be cleaned from udev if the vtuner driver correctly unloads when close is called.

Someone from core team please verify this.



Re: it913x USB DVB-T tuner reported as DVB-C after GUI restart #60 malakudi

  • PLi® Core member
  • 1,449 posts

+68
Good

Posted 22 January 2014 - 09:52

Can anyone from core developers comment about the issue of the driver? Is it as I have interpreted? Please reply in order to proceed with reporting the issue to VU+.


Edited by malakudi, 22 January 2014 - 09:52.






Also tagged with one or more of these keywords: OpenPLi4, it913x, Vu+ Duo2

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users