Hi Marten,
would not that be interesting? ;)https://github.com/raspberrypi/firmware/commit/b5898de75d8f2c4e5c42d81acf2fbad81c669808 (https://github.com/raspberrypi/firmware/commit/b5898de75d8f2c4e5c42d81acf2fbad81c669808)
Yes this is interesting., the question is if it also uses the Image fx filter ....
Hi,
http://forum.loggytronic.com/index.php?topic=634.msg3547#msg3547 (http://forum.loggytronic.com/index.php?topic=634.msg3547#msg3547)
I will update the firmware and enable it ... ^^^ . omxplayer it also makes. ;)
-->https://github.com/huceke/omxplayer/commit/8599b66d77c9196831b3e717b669d33a96df9bcb (https://github.com/huceke/omxplayer/commit/8599b66d77c9196831b3e717b669d33a96df9bcb)
Well, that looks easy, any way I can update git in the moment, I am currently away from my pi and I am working on openvg.
Marten
it should be limited to SD and 1080i (not 720p) ... something crashes here, I look at tomorrow ...
Quote from: Uwe on September 25, 2012, 21:16:58
it should be limited to SD and 1080i (not 720p) ... something crashes here, I look at tomorrow ...
I have now changed to
if (deinterlace!=0 && demux->getHorizontalSize()<=720 || deinterlace!=0 && demux->getHorizontalSize()>=1920) But my vdr-1.7.30 crashes, when i access with vompclient-raspi... vdr-1.7.29 works with vompserver-git. Can anyone confirm this?
Quote#0 0x0811dd10 in cReceiver::~cReceiver() ()
No symbol table info available.
#1 0xb5488746 in MVPReceiver::~MVPReceiver() () from /usr/lib/vdr/plugins/libvdr-vompserver.so.1.7.30
No symbol table info available.
#2 0xb54887c2 in MVPReceiver::~MVPReceiver() () from /usr/lib/vdr/plugins/libvdr-vompserver.so.1.7.30
No symbol table info available.
#3 0xb547aa2c in VompClientRRProc::processStopStreaming() () from /usr/lib/vdr/plugins/libvdr-vompserver.so.1.7.30
No symbol table info available.
#4 0xb547cf20 in VompClientRRProc::processPacket() () from /usr/lib/vdr/plugins/libvdr-vompserver.so.1.7.30
No symbol table info available.
#5 0xb547d29e in VompClientRRProc::threadMethod() () from /usr/lib/vdr/plugins/libvdr-vompserver.so.1.7.30
No symbol table info available.
#6 0xb547fbd1 in Thread::threadInternalStart2() () from /usr/lib/vdr/plugins/libvdr-vompserver.so.1.7.30
No symbol table info available.
#7 0xb547fc2b in threadInternalStart(void*) () from /usr/lib/vdr/plugins/libvdr-vompserver.so.1.7.30
No symbol table info available.
#8 0xb7788053 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#9 0xb74e16ce in clone () from /lib/libc.so.6
No symbol table info available.
...
Thread 21 (Thread 30546):
#0 0xffffe424 in __kernel_vsyscall ()
No symbol table info available.
#1 0xb74da461 in select () from /lib/libc.so.6
No symbol table info available.
#2 0xb546ef8f in DatagramSocket::waitforMessage(unsigned char) () from /usr/lib/vdr/plugins/libvdr-vompserver.so.1.7.30
No symbol table info available.
#3 0xb5470063 in UDPReplier::threadMethod() () from /usr/lib/vdr/plugins/libvdr-vompserver.so.1.7.30
No symbol table info available.
#4 0xb547fbd1 in Thread::threadInternalStart2() () from /usr/lib/vdr/plugins/libvdr-vompserver.so.1.7.30
No symbol table info available.
#5 0xb547fc2b in threadInternalStart(void*) () from /usr/lib/vdr/plugins/libvdr-vompserver.so.1.7.30
No symbol table info available.
#6 0xb7788053 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#7 0xb74e16ce in clone () from /lib/libc.so.6
No symbol table info available.
...
Thread 24 (Thread 30548):
#0 0xffffe424 in __kernel_vsyscall ()
No symbol table info available.
#1 0xb778fdc8 in accept () from /lib/libpthread.so.0
No symbol table info available.
#2 0xb546f4ec in MVPServer::threadMethod() () from /usr/lib/vdr/plugins/libvdr-vompserver.so.1.7.30
No symbol table info available.
#3 0xb547fbd1 in Thread::threadInternalStart2() () from /usr/lib/vdr/plugins/libvdr-vompserver.so.1.7.30
No symbol table info available.
#4 0xb547fc2b in threadInternalStart(void*) () from /usr/lib/vdr/plugins/libvdr-vompserver.so.1.7.30
No symbol table info available.
#5 0xb7788053 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#6 0xb74e16ce in clone () from /lib/libc.so.6
No symbol table info available.
Thread 23 (Thread 30547):
#0 0xffffe424 in __kernel_vsyscall ()
No symbol table info available.
#1 0xb74da461 in select () from /lib/libc.so.6
No symbol table info available.
#2 0xb546ef8f in DatagramSocket::waitforMessage(unsigned char) () from /usr/lib/vdr/plugins/libvdr-vompserver.so.1.7.30
No symbol table info available.
#3 0xb547716b in MVPRelay::threadMethod() () from /usr/lib/vdr/plugins/libvdr-vompserver.so.1.7.30
No symbol table info available.
#4 0xb547fbd1 in Thread::threadInternalStart2() () from /usr/lib/vdr/plugins/libvdr-vompserver.so.1.7.30
No symbol table info available.
#5 0xb547fc2b in threadInternalStart(void*) () from /usr/lib/vdr/plugins/libvdr-vompserver.so.1.7.30
No symbol table info available.
#6 0xb7788053 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#7 0xb74e16ce in clone () from /lib/libc.so.6
No symbol table info available.
...
Thread 32 (Thread 16990):
#0 0xffffe424 in __kernel_vsyscall ()
No symbol table info available.
#1 0xb778917e in pthread_join () from /lib/libpthread.so.0
No symbol table info available.
#2 0xb547fe09 in Thread::threadStop() () from /usr/lib/vdr/plugins/libvdr-vompserver.so.1.7.30
No symbol table info available.
#3 0xb547ca1a in VompClientRRProc::~VompClientRRProc() () from /usr/lib/vdr/plugins/libvdr-vompserver.so.1.7.30
No symbol table info available.
#4 0xb5474964 in VompClient::~VompClient() () from /usr/lib/vdr/plugins/libvdr-vompserver.so.1.7.30
No symbol table info available.
#5 0xb5474a6e in VompClientStartThread(void*) () from /usr/lib/vdr/plugins/libvdr-vompserver.so.1.7.30
No symbol table info available.
#6 0xb7788053 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#7 0xb74e16ce in clone () from /lib/libc.so.6
No symbol table info available.
@Uwe
Can you please run this with a build containing debugging symbols. (Please look at the manual of your distribution how to do this, normally for building it is a switch -g but it can be more complicated as in the case of debian)
Then please let the system create core files (activate with uname -c unlimited)
I need to know the exact line where it crashes with the value of the surronding variables.
Marten
P.S: I do not have the time to debug this myself, I want first to make progress to the client before I do an update of the server.
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.
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.
Yes, thanks, now I know what to do, so please add in mvpreceiver.h after
bool isVdrActivated();the code
void detachMVPReceiver();The add to mvpreceiver.cc
Quotevoid detachMVPReceiver(){
Detach();
}
Remove Detach from
MVPReceiver::~MVPReceiver()
and then add in VompClientRRProc::processStopStreaming
before
delete x.lp;the code
Quotex.detachMVPReceiver();
Then test it and if it works, send a patch to Chris and post it to the forum.
Marten
That was fast! :)
I still have a problem!
( 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
My fault it should be
x.lp.detachMVPReceiver();
Quote from: MartenR on October 02, 2012, 11:40:26
My fault it should be
x.lp.detachMVPReceiver();
Mhh, next fault is here... :)
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
Yep you are right:
x.lp->detachMVPReceiver();
should do it.
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
So at least one bug fixed.
This is something different.
Can you please tell me which value result and which values this in cCharSetConv has?
Thanks Marten.
Send a patch to Chris.
Hope we see it soon in git. ::)
The problem is I am not sure, if this really fixes the problem or if it is asymptom.
I do not recommend to include it in git now.
Marten
Quote from: MartenR on October 03, 2012, 09:29:41
The problem is I am not sure, if this really fixes the problem or if it is asymptom.
I do not recommend to include it in git now.
Marten
I tested it now, and I believe it fixes only the half. Main vdr will not be killed anymore, but channelswitching is not working.
It works for me if I revert this changes.
- Fixed a race condition when zapping in transfer mode (reported by Reinhard Nissl).
This involves a slight change in the semantics of the cReceiver::Activate() function,
which is now called with 'false' *after* the receiver has been detached from the
device.
diff -ruN vdr-1.7.29/device.c vdr-1.7.30/device.c
--- vdr-1.7.29/device.c 2012-04-04 11:48:21.000000000 +0200
+++ vdr-1.7.30/device.c 2012-08-26 15:25:44.000000000 +0200
@@ -1666,11 +1675,11 @@
cMutexLock MutexLock(&mutexReceiver);
for (int i = 0; i < MAXRECEIVERS; i++) {
if (receiver[i] == Receiver) {
- Receiver->Activate(false);
Lock();
receiver[i] = NULL;
Receiver->device = NULL;
Unlock();
+ Receiver->Activate(false);
for (int n = 0; n < Receiver->numPids; n++)
DelPid(Receiver->pids[n]);
}
QuoteIt works for me if I revert this changes.
Are all problems gone, if you revert these changes in vdr?
Marten
Quote from: MartenR on October 03, 2012, 10:03:22
QuoteIt works for me if I revert this changes.
Are all problems gone, if you revert these changes in vdr?
Marten
Yes.
Can you please try the following:
remove "threadStop();" from the destructor of mvpreceiver.
Then put it before Detach in DetachMvpReceiver.
Also add in the destructor of Vompclient a call to lp->DetachMvpReceiver() before delete lp;
Marten
Many thanks to you both MartenR and hondansx!
Now with vdr-1.7.31 everything works again!
And here's the complete patch... :)
--- 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;
}
I can confirm that this patch works for me too.
@Marten
Can you recommend this for git?
@Chris
If okay, can you put this into the git?
Yes I can, except that I also want a call to
lp->detachMVPReceiver();in the vompclient destructor.
Marten
Hi,
That could be interesting...
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=29&t=19334 (http://www.raspberrypi.org/phpBB3/viewtopic.php?f=29&t=19334)
I have applied the patch to vompserver git. Thanks hondansx, Uwe and MartenR for fixing that.
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:
if (deinterlace!=0 && demux->getHorizontalSize()<=720 || deinterlace!=0 && demux->getHorizontalSize()==1920)
I do not activate the deinterlacer until the new firmware went into raspbian.
But in the mean time I change part in the demuxer to parse deinterlacing information,
which should prevent, if the flags are set correctly by the tv station, deinterlacing progressive material.
You can now activate the deinterlacer for HD material with:
if (deinterlace!=0 && demux->getInterlaced())
if you have the right firmware.
Marten
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. :D Super!
I think they reverted some changes in the firmware in order to release soon a firmware for 512MB.
So it might be that the functionality might come back later.
Marten
If you comment the return in
void VideoOMX::interlaceSwitch4Demux()
there is an experimental feature, switching of the interlacing mode of 1080, depending on the source material.
Marten