Forums

This looks a bit like the sequence I'm seeing when I am entering a recording from http in the timer list. And then also enigma hangs. So it seems there is at least "something" going on.

Hello,

We had a little chatting with @pieterg about this issue and once again @pieterg found the simplest (and simple is better) solution.

So when we are trying to insert EGP from IPTV there is no need to start iTsSource, so we never get to the point where the deadlock is happening.

--- a/lib/service/servicedvbrecord.cpp
+++ b/lib/service/servicedvbrecord.cpp
@@ -255,7 +255,7 @@ int eDVBServiceRecord::doPrepare()
                m_pids_active.clear();
                m_state = statePrepared;
                ePtr<iTsSource> source;
-               if (!m_ref.path.empty())
+               if (!m_simulate && !m_ref.path.empty())
                {
                        if (m_is_stream_client)

Thanks once again @pieterg.

PS. I will not commit above code, it's @pieterg idea
PPS. Works For Me.
Veranderd door athoik, 5 december 2013 - 21:17

This looks exactly like the problem I am having (or, better, the solution to it)!

 

I'll try it tomorrow

ok, thanks for testing, I'll commit this fix.
(though the actual deadlock indicates there is another issue as well, most likely in the eThread class)

I can now at least enter the remote service as a daily timer, which I couldn't do before, yeay! 

 

Now let's see if the actual recording also works....

... initially not (zero sized recording)

... now testing with "record & zap" timer ... no doesn't do the trick either (again zero size)

... testing with zap timer before record timer ... nope

 

That's interesting because it does work when the timer is becoming active when the receiver is already on the channel.

 

Bummer

Hello @Erik Slagter,


I think i read a post by @pieterg, and was mentioning that recording with eDVBServiceRecord actually downloads the stream twice!

So if the remote service allows only one stream (the one you are watching) then most probably that is the problem.

Yes, you read that correctly, but, it's no problem, because enigma always allows one service to be streamed twice (or more).

 

I am testing with the "remote" receiver (the one that has the tuner) being in stand-by, so the tuner is always free. If I do the same thing with a plain and simple wget from my pc it works. It also works if I start the stream twice. So, the problem is not on the remote side, it's on the local side, the enigma that's receiving the stream.

 

It looks like it's searching for a PAT/PMT and never finds it. It can also be yet another bug in the pid filtering of vuplus (I am using a solo2 on the local side), I wouldn't be surprised actually. I really ought to test it with another brand "local" receiver, but I haven't got one spare at the moment.

 

For the remote tuner thing being really succesful (as in: use remote tuners as if they're local) I think it's essential that you can record from them...

Please take a look at the following: http://openpli.org/f...-19#entry389948

It is enabling a867 and af9035 dvb-t stick for vu 3.1 kernel.

Patches where already available and used by dreambox, but they didn't apply nicely (Makefile ony) on vu 3.1 kernel.

Thanks

(though the actual deadlock indicates there is another issue as well, most likely in the eThread class)

There's a deadlock built-in in eThread. The destructor calls virtual methods, this is never going to work for the same reason as calling virtual methods from the constructor will fail to work as expected.

When the eThread constructor is being called, the class has already been demoted to its base eThread class, and any data owned by the derived class is now in Limbo. The attempt to "join" the thraed will usually fail.

The eTread class is broken by design (you can see some "why do I have to call kill here" remarks in the code as a result). Your derived class MUST call "kill" or otherwise stop the thread BEFORE the destructor is called, otherwise the destructor will hang, or the thread code will crash, or both.

LOL looks like something similar in a piece of code I made some time ago. It couldn't be done the "nice" way, exactly as you describe, because the virtual class was already gone at that stage. I noticed from crashing Interesting enigma doesn't crash on similar code.

 

I am very interested in a solution because that will probably solve the recording from remote service doesn't do anything problem.

Hello,

The following patch will enable a867 and af9035 for vu 3.1 kernel.

--- a/meta-openpli/recipes-linux/linux/linux-vuplus-3.1.1.inc
+++ b/meta-openpli/recipes-linux/linux/linux-vuplus-3.1.1.inc
@@ -3,7 +3,7 @@ LICENSE = "GPL"
 SECTION = "kernel"
 KV = "3.1.1"
 
-PR_INC = ".8"
+PR_INC = ".9"
 
 SRCREV = "r2"
 
@@ -22,6 +22,8 @@ SRC_URI += "http://archive.vuplus.com/download/kernel/linux-${KV}_${SRCREV}.tar.
         file://em28xx_fix_terratec_entries.patch \
         file://em28xx_add_terratec_h5_rev3.patch \
 	file://fix-dvb-siano-sms-order.patch \
+	file://dvb-usb-af9035.patch \
+	file://dvb-usb-a867.patch \
         file://${MACHINE}_defconfig \
         "

Patches where available but they didn't apply nicely on 3.1 kernel (Makefile patching was failing).

I don't have such a usb stick in order to test it. Compiled kernel modules are available here : http://openpli.org/f...not-on-vu-solo/ , altough the reporter never downloaded modules (probably black hole suck him )

 

Any chance commiting above?

 

Also if possible please add rtl2832 patch http://sourceforge.n...-rtl2832.patch.

Hello,
 
 
New patch created with rtl2832 also!
 
 

Subject: [PATCH] vuplus 3.1.1: Add support for more DVB-T usb sticks

Add missing patches for a867,af9035 and rtl2832 DVB-T stick.
Patches were available but Makefile/Kconfig didn't apply nice on vu 3.1 kernel.
Thanks to all people make available those patches at first time.

diff --git a/meta-openpli/recipes-linux/linux/linux-vuplus-3.1.1.inc b/meta-openpli/recipes-linux/linux/linux-vuplus-3.1.1.inc
index 828aab9..095b51c 100644
--- a/meta-openpli/recipes-linux/linux/linux-vuplus-3.1.1.inc
+++ b/meta-openpli/recipes-linux/linux/linux-vuplus-3.1.1.inc
@@ -3,7 +3,7 @@ LICENSE = "GPL"
 SECTION = "kernel"
 KV = "3.1.1"
 
-PR_INC = ".8"
+PR_INC = ".9"
 
 SRCREV = "r2"
 
@@ -22,6 +22,9 @@ SRC_URI += "http://archive.vuplus.com/download/kernel/linux-${KV}_${SRCREV}.tar.
         file://em28xx_fix_terratec_entries.patch \
         file://em28xx_add_terratec_h5_rev3.patch \
 	file://fix-dvb-siano-sms-order.patch \
+	file://dvb-usb-af9035.patch \
+	file://dvb-usb-a867.patch \
+	file://dvb-usb-rtl2832.patch \
         file://${MACHINE}_defconfig \
         "

 
 0001-vuplus-3.1.1-Add-support-for-more-DVB-T-usb-sticks.zip   604,25K   12 Aantal bijlagen
 
Here also compiled kernel modules for vuultimo.
 
 kernel-module-dvb-usb-af9035_3.1.1-r0_vuultimo.ipk   9,18K   4 Aantal bijlagen
 kernel-module-dvb-usb-a867_3.1.1-r0_vuultimo.ipk   72,54K   2 Aantal bijlagen
 kernel-module-dvb-usb-rtl2832_3.1.1-r0_vuultimo.ipk   140,27K   8 Aantal bijlagen
 
Please commit this one
Veranderd door athoik, 29 december 2013 - 09:50

thank you very much athoik

are there in pli feeds/drivers ? 

No there are not.

 

If it works sucessully... remind @OpenPLi to commit this.

What exactly needs to be applied? Is it only the patch from #392?

Yes, please commit #392 (#392 includes changes from #372 also)

Veranderd door athoik, 4 januari 2014 - 10:07

Hello,

 

Here is a patch for OpenPLi 4 OE that backports many fixes for it913x dvb-t into 3.2 kernel.

 

 0001-it913x-backport-changes-to-3.2-kernel-for-OE.patch.txt   69,56K   7 Aantal bijlagen

 

More info and compiled kernel modules (from dm800se & dm500hd) here: http://openpli.org/f...c/28764-it9135/

 

Thanks,

I think pieterg should have a look at this, whether it won't hurt any other magic we do in the kernel

If it compiles and runs, it's fine by me.

"It compiles" 

 

Athoik can you please confirm it's all in commit d41fa46527bc7b20697c3265345416a6f76ab83d? I could have missed something, because there are many topics about this, all with patches.