[mythtv-users] MythPhone causes mythfrontend to lock??

[Jim Kusznir]

I tried last night, with CVS (pulled down approx. 1am Tues GMT).  I 
never got to end a call with stop, as it always froze before then.  It 
is definately working better than the 0.16 release, though.  One time my 
local video froze (for the other end as well as mine), but the local 
video remained in tact.  I was able to exit and restart only mythphone 
to fix this.

I did get some calls as long as 15 min in, but also a lot that were 2-4 
min before lockup.  It is still locking up the entire frontend 
(requiring a killall mythfrontend to recover from).

I watched top while in a video call.  System load was around 2.1 with X 
using approx 30% and mythfrontend using 20%.  The percentages at the top 
showed a high "sys" percentage.

I am calling a video station over a thousand miles away.  We both have 
cablemodem, but different vendors, so I would suspect the data stream is 
not nearly as clean as a local lan.

Oh, and I'm also not using the audio portions; I can't get mythphone to 
find/use audio from my soundcard's mic port.  (Using the alsamixer, I 
can get my mic looped to the speakers through the mixer, but it seems no 
amount of fiddling with capture device and other routing stuff can get 
mythphone to find my mic.  I suspect this is a config issue on my end, 
as myth appeared to compile using OSS rather than ALSA, and I haven't 
found any way to test/tweak the OSS settings explicitly).

Thanks for your support!

If there's any more detals I can provide or anything else I can do, let 
me know.  MythPhone is a really useful app!

--Jim

Paul Volkaerts wrote:

>Just an update on this; I just placed a 2 hour, full-screen video call
>between my two machines at 384x288 resolution. Video lasted the whole 2
>hours though the audio hung after 45 mins on one machine. My machines are a
>P4 2.8GHz with 512M and a AMD Athlon 950MHz with 256M memory. When I stop
>the call and exit from MythPhone then MythFrontend hangs, not sure where - I
>will look at this next.
>
>Many fixes went in over the weekend so if you could retry with these and let
>me know we can go from there.
>
>Cheers;
>Paul
>
>  
>
>>-----Original Message-----
>>From: mythtv-users-bounces at mythtv.org
>>[mailto:mythtv-users-bounces at mythtv.org]On Behalf Of Jim Kusznir
>>Sent: 03 January 2005 22:07
>>To: Discussion about mythtv
>>Subject: Re: [mythtv-users] MythPhone causes mythfrontend to lock??
>>
>>
>>I've installed the CVS version (from 29Dec).  The frontend locking
>>during normal video call has stopped; however, there are a few other
>>problems now.
>>
>>I like the presence detect; unfortunately, it doesn't appear to work.
>>It shows someone who is definately online as offline and consequently
>>won't let me dial them through the speedial.  If I dial the person
>>manually (enter the number), then the call often goes through, and the
>>presence on the speedial shows a green dot and says (unknown).
>>
>>When I hit the stop button to end the call, the frontend froze.
>>
>>During another call, I hit play to go fullscreen; both the remote (main)
>>video and the local (pip) video drew, but the frontend locked almost
>>immediately afterward.
>>
>>I'm running this on a gentoo system with PIII-733Mhz and 384MB ram.  It
>>seems to run mythtv just fine otherwise.
>>
>>Any suggestions? (other than upgrade my hardware :) )
>>
>>--Jim
>>
>>Paul Volkaerts wrote:
>>
>>    
>>
>>>Mythphone runs as several threads.  The audio and RTP is one
>>>      
>>>
>>thread, the SIP
>>    
>>
>>>stack is one thread, and the RTP for video is one thread. The H.263 and
>>>displaying of webcams runs in the main GUI thread currently
>>>      
>>>
>>though I do want
>>    
>>
>>>to change this. This means when H.263 locks up, so does the GUI.
>>>
>>>I test MythPhone between two MythFrontends and between MythFrontend and
>>>Windows Messenger. Version 0.16 was reasonably stable on good
>>>      
>>>
>>CPUs. I have a
>>    
>>
>>>3GHz P4 which it runs perfectly on and a 1GHz CPU that often exhibits the
>>>behaviour you mention.
>>>
>>>Since 0.16 there have been many changes which may help your situation. I
>>>have taken out most of the polling that originally drove the tasks and
>>>replaced by event-driven. The only polling now is polling of the
>>>      
>>>
>>microphone
>>    
>>
>>>driver for data which I will get rid of when I figure out how to.
>>>
>>>I've also fixed an incompatability with Messenger which caused a
>>>      
>>>
>>video frame
>>    
>>
>>>split across several IP packets to be reconstructed incorrectly, which
>>>caused the H.263 stack to discard it.
>>>
>>>Paul
>>>
>>>
>>>
>>>
>>>      
>>>
>>>>-----Original Message-----
>>>>From: mythtv-users-bounces at mythtv.org
>>>>[mailto:mythtv-users-bounces at mythtv.org]On Behalf Of Jim Kusznir
>>>>Sent: 02 January 2005 07:25
>>>>To: mythtv-users at mythtv.org
>>>>Subject: [mythtv-users] MythPhone causes mythfrontend to lock??
>>>>
>>>>
>>>>Hello all:
>>>>
>>>>I've been having continous problems with the 0.16 version of mythphone
>>>>causing the frontend to lock.
>>>>
>>>>I have a usb webcam set up (with mythphone set to use /dev/video1), and
>>>>mythpone correctly shows my local video.  I'm connected to FWD (Free
>>>>World Dialup).  Everything is fine in this idle state (showing my local
>>>>video, registered with FWD but not in a call).
>>>>
>>>>When I place a video call to another FWD user (who's using the Pulver
>>>>Communicator under WinXP with a web cam and proper local video), it
>>>>often works for at least a few seconds (Occasionally even for a few
>>>>minutes).  I'm able to see and hear the other person, and the other
>>>>person sees me (but can't hear me -- that's a different problem,
>>>>though).  The call lasts anywhere from 1 sec to 10 minutes, but at some
>>>>point the frontend freezes completely.  Interestingly enough, I can
>>>>continue to hear the other person, but both of my video windows are
>>>>frozen, and the video she recieves is frozen (based on what the other
>>>>person described of the remote client, it is not recieving video signals
>>>>anymore).  My only recourse at this point is to kill mythfrontend and
>>>>relaunch it.
>>>>
>>>>I've played a bit with the resolutions and fps and found the values do
>>>>seem to have a signifiant effect on call duration (most resolutions and
>>>>fps over 10 cause the frontend to freeze more quickly; fps below 10
>>>>don't seem to effect freeze rate, but can often take way too long to
>>>>fully draw the remote end).
>>>>
>>>>When I run mythfrontend in a terminal and collect its stderr output, I
>>>>get output like:
>>>>
>>>>[h263 @ 0xb7a761d0]illegal ac vlc code at 0x7
>>>>[h263 @ 0xb7a761d0]Error at MB: 84
>>>>[h263 @ 0xb7a761d0]concealing 2147483614 errors
>>>>Error decoding frame; 1443
>>>>[h263 @ 0xb7a761d0]illegal dc 0 at 0 4
>>>>[h263 @ 0xb7a761d0]illegal dc 128 at 1 4
>>>>[h263 @ 0xb7a761d0]I cbpc damaged at 9 4
>>>>[h263 @ 0xb7a761d0]Error at MB: 57
>>>>[h263 @ 0xb7a761d0]concealing 2147483647 errors
>>>>[h263 @ 0xb7a761d0]I cbpy damaged at 0 7
>>>>[h263 @ 0xb7a761d0]Error at MB: 84
>>>>[h263 @ 0xb7a761d0]concealing 2147483647 errors
>>>>[h263 @ 0xb7a761d0]Error at MB: 84
>>>>[h263 @ 0xb7a761d0]concealing 2147483647 errors
>>>>[h263 @ 0xb7a761d0]illegal dc 0 at 0 8
>>>>[h263 @ 0xb7a761d0]concealing 9 errors
>>>>[h263 @ 0xb7a761d0]Error at MB: 96
>>>>[h263 @ 0xb7a761d0]concealing 2147483647 errors
>>>>[h263 @ 0xb7a761d0]Error at MB: 84
>>>>[h263 @ 0xb7a761d0]concealing 2147483647 errors
>>>>[h263 @ 0xb7a761d0]I cbpy damaged at 0 8
>>>>[h263 @ 0xb7a761d0]Error at MB: 96
>>>>[h263 @ 0xb7a761d0]concealing 2147483647 errors
>>>>
>>>>These messages generally occur at 2-4 lines per second, and occur the
>>>>entire duration of the call.  I see no errors that hint at or relate to
>>>>the freeze.
>>>>
>>>>So...questions...
>>>>
>>>>I've recently retrieved the CVS versions of mythtv and associated
>>>>modules.  I'm still working on a clean way to install them on my system
>>>>(gentoo).  In any case, I haven't been able to deturmine if anything's
>>>>been done to mythphone that might address this issue.
>>>>
>>>>I'd be greatful of any assistance one can offer...
>>>>
>>>>--Jim
>>>>        
>>>>