Messages

I have contacted the firmware developers and they are aware of the bug.
Anyway, dom from the raspbarry pi forum told me, that you can revert to an old working firmware with

Code Select Expand

rpi-update d6b57e4dad12353f291dae03ecfaf852d2d9fcce
or just wait a bit.

Yeeaahh, finally works again 1080i @ h264. Many many thanks for the Info!
Although now only have 256MB of RAM instead of 512MB, but the fix will hopefully soon ...

Thank you!
I had the day before all the plugins updated by script ... and therefore the patch was back outside...

Code Select Expand

   git reset --hard HEAD
   git clean -f -d
   git pull


Hi,
here i get an error when starting the vompclient. (Protocoll mismatch s: 0 c: 100)
What's going wrong here?

[Steckerleiste]

TV and Raspi are switched off by Steckerleiste.

Dat is net witzsich, was heißt "Steckerleiste" auf inglisch? 

--> power strip?

But it is because i use the automatic translation, sometimes he does not know the words.

[Steckerleiste]

TV and Raspi are switched off by Steckerleiste.

Hi Marten,
Thanks for the Tip. ... but ...
With the latest firmware and vompclient-git version -> 1080i channels no longer work, only ServusTV HD works, but as AnixeHD and other not work. (Deinterlacer is deaktivated)
(Image starts, sound comes, stand freezes, sound continues for 5 seconds and then falls silent.)
AND ... 720p Channels works fine, without micro stuttering. Super!

Hi Marten,
the code is working with you? Here it does not work with that, too. Error as above by clausmus...

Hi,
i have update my raspbian to https://github.com/Hexxeh/rpi-firmware
I now have a CPU usage of 35% to 90% max by 1080i Channels (eg. ServusTV-HD or DiscoveryHD) with deinterlacer on 720p Mode(hdmi_mode=19   # 720p 50Hz) I have almost no stuttering. (can it be that the new firmware can scale better?)
At 720p Channel i have still this micro stuttering. (I saw that the new GPU firmware can more memory request ... Could be in the vompclient change?)
Overall I think that it works better with this change.
I hope it will soon work with 720p even better...

1080i deinterlacer aktivate with:

Code Select Expand

if (deinterlace!=0 && demux->getHorizontalSize()<=720 || deinterlace!=0 && demux->getHorizontalSize()==1920)

Hi,
That could be interesting...
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=29&t=19334

Most issues of this thread should now be closed. See recent git changes.

The new version in the git looks very nice. HD and SD so far worked without stuttering.

Many many thanks.

Uwe

Many thanks to you both MartenR and hondansx!
Now with vdr-1.7.31 everything works again!

And here's the complete patch...

Code Select Expand

--- vompserver-git//mvpreceiver.c       2012-10-03 11:41:07.907972907 +0200
+++ vompserver-new//mvpreceiver.c       2012-10-03 11:55:41.343970348 +0200
@@ -78,8 +78,8 @@

MVPReceiver::~MVPReceiver()
{
-  Detach();
-  threadStop();

   numMVPReceivers--;
   Log::getInstance()->log("MVPReceiver", Log::DEBUG, "num mvp receivers now down to %i", numMVPReceivers);
@@ -106,6 +106,11 @@
   return vdrActivated;
}

+void MVPReceiver::detachMVPReceiver(){
+   threadStop();
+   Detach();
+}
+
void MVPReceiver::Receive(UCHAR* data, int length)
{
   pthread_mutex_lock(&processedRingLock);
@@ -171,3 +176,4 @@
   *destpids=0;
   return mergedSpidsTpid;
}
diff -Nur vompserver-git//mvpreceiver.h vompserver-new//mvpreceiver.h
--- vompserver-git//mvpreceiver.h       2012-10-03 11:41:07.907972907 +0200
+++ vompserver-new//mvpreceiver.h       2012-10-02 12:18:25.447956834 +0200
@@ -38,6 +38,7 @@
     virtual ~MVPReceiver();
     int init(TCP* tcp, ULONG streamID);
     bool isVdrActivated();
+    void detachMVPReceiver();

   private:
     MVPReceiver(cChannel* channel, cDevice* device);
diff -Nur vompserver-git//vompclientrrproc.c vompserver-new//vompclientrrproc.c
--- vompserver-git//vompclientrrproc.c  2012-10-03 11:41:07.911972907 +0200
+++ vompserver-new//vompclientrrproc.c  2012-10-03 11:53:51.727970671 +0200
@@ -1113,6 +1113,7 @@
   log->log("RRProc", Log::DEBUG, "STOP STREAMING RECEIVED");
   if (x.lp)
   {
+    x.lp->detachMVPReceiver();
     delete x.lp;
     x.lp = NULL;
   }

Hi Marten,
Now it works a little bit.
If I were to quickly switch to another channel or an HD channel use, then it crashes.
The Attachment even a complete log set

My fault it should be

Code Select Expand

x.lp.detachMVPReceiver();

Mhh, next fault is here...

Code Select Expand

g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC -ggdb -O0 -c -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DUSE_CUTTERLIMIT -DUSE_DDEPGENTRY -DUSE_HARDLINKCUTTER -DUSE_JUMPINGSECONDS -DUSE_JUMPPLAY -DUSE_LIRCSETTINGS -DUSE_LIEMIKUUTIO -DUSE_MAINMENUHOOKS -DUSE_MENUORG -DUSE_NALUDUMP -DUSE_PLUGINMISSING -DUSE_WAREAGLEICON -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"vompserver"' -DVOMPSERVER -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -I../../../include -I/include -o vompclientrrproc.o vompclientrrproc.c
vompclientrrproc.c: In member function >int VompClientRRProc::processStopStreaming()<:
vompclientrrproc.c:1116:10: error: request for member >detachMVPReceiver< in >((VompClientRRProc*)this)->VompClientRRProc::x->VompClient::lp<, which is of non-class type >MVPReceiver*<
make: *** [vompclientrrproc.o] Error 1

That was fast!
I still have a problem!

Code Select Expand

( if [ -f .standalone ] ; then ( rm -f .standalone; make clean ; make objects ) ; else exit 0 ;fi )
g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC -ggdb -O0 -c -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DUSE_CUTTERLIMIT -DUSE_DDEPGENTRY -DUSE_HARDLINKCUTTER -DUSE_JUMPINGSECONDS -DUSE_JUMPPLAY -DUSE_LIRCSETTINGS -DUSE_LIEMIKUUTIO -DUSE_MAINMENUHOOKS -DUSE_MENUORG -DUSE_NALUDUMP -DUSE_PLUGINMISSING -DUSE_WAREAGLEICON -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"vompserver"' -DVOMPSERVER -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -I../../../include -I/include -o vompclientrrproc.o vompclientrrproc.c
vompclientrrproc.c: In member function >int VompClientRRProc::processStopStreaming()<:
vompclientrrproc.c:1116:5: error: >class VompClient< has no member named >detachMVPReceiver<
make: *** [vompclientrrproc.o] Error 1

Hi Marten.
I hope this is now what you need?
I start with the vompclient a HD channel, eg ARD HD. If i switch to a next channel, the image remains on the raspberry stand. The VDR Server ruled no more. I must kill the vompclient with "killall -9 vompclient". This creates the log is as shown below.

Code Select Expand

Thread 1 (Thread 24897):
#0  0x0812248f in cReceiver::~cReceiver (this=0x84edfc0, __in_chrg=<value optimized out>) at receiver.c:28
        msg = 0x818a6b8 "ERROR: cReceiver has not been detached yet! This is a design fault and VDR will segfault now!"
#1  0xb4698dad in MVPReceiver::~MVPReceiver (this=0x84edfc0, __in_chrg=<value optimized out>) at mvpreceiver.c:79
No locals.
#2  0xb4698e33 in MVPReceiver::~MVPReceiver (this=0x84edfc0, __in_chrg=<value optimized out>) at mvpreceiver.c:86
No locals.
#3  0xb46860d2 in VompClientRRProc::processStopStreaming (this=0x84ed4a0) at vompclientrrproc.c:1116
No locals.
#4  0xb468287b in VompClientRRProc::processPacket (this=0x84ed4a0) at vompclientrrproc.c:199
        result = 0
#5  0xb4682685 in VompClientRRProc::threadMethod (this=0x84ed4a0) at vompclientrrproc.c:147
No locals.
#6  0xb468d521 in Thread::threadInternalStart2 (this=0x84ed4a0) at thread.c:37
No locals.
#7  0xb468d502 in threadInternalStart (arg=0x84ed4a0) at thread.c:32
        sigs = {__val = {2147483647, 4294967294, 4294967295 <repeats 30 times>}}
        t = 0x84ed4a0
#8  0xb771e053 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#9  0xb74776ce in clone () from /lib/libc.so.6
No symbol table info available.