:: #mythtv

Daily chat history

Current users (91):

aloril, andreax, Anduin_, Andy50, Anssi, anykey_, beata, Beirdo, brfransen, cattelan_away, Chutt, clever, coling, Cougar, dagar, danielk22, Dave123, Dave123-road, dlblog, eharris, exelnet_, f33dMB, foxbuntu, fp__, ghoti, Gibby, gregL, GreyFoxx, Guest84520, highzeth, hobiga, iamlindoro, ikonia, J-e-f-f-A, j-rod|afk, jams, jarle, jcarlos, JEDIDIAH__, joe_, jpabq, jpabq-, jpharvey, jstenback, justinh, jwhite, kc, kisak, knightr, kormoc_afk, kurre, kwmonroe, laga, len, mag0o, markk, MaverickTech, mrand, MythBuild, MythLogBot, NightMonkey, noahric_, okolsi, paul-h, pheld, PointyPumper, poptix, purserj, rhpot1991, sailerboy, Seeker`, simonckenyon, skd5aner, Snow-Man, sphery, stuarta, stuartm, sunkan, superm1, sutula, tgm4883, tomimo, tris, Unhelpful, wahrhaft, weta, wylie, xris, xxtjaxx, zombor, _charly_
Monday, May 23rd, 2011, 00:22 UTC
[00:22:25] kisak: stuartm: the odd thing about that to me is that a recording made by mythtv 0.24 last August also has spots which die at line 268
[00:22:55] kisak: it did not have trouble back then
[00:47:40] ischyrus (ischyrus!~ischyrus@ has quit (Quit: Computer has gone to sleep.)
[00:48:16] gigem_ (gigem_!~david@mythtv/developer/gigem) has quit (Remote host closed the connection)
[00:48:43] gigem_ (gigem_! has joined #mythtv
[00:48:43] gigem_ (gigem_! has quit (Changing host)
[00:48:43] gigem_ (gigem_!~david@mythtv/developer/gigem) has joined #mythtv
[01:04:44] dblain (dblain!~dblain@mythtv/developer/dblain) has quit (Read error: Connection reset by peer)
[01:06:19] eharris (eharris! has quit (Ping timeout: 240 seconds)
[01:07:51] eharris (eharris! has joined #mythtv
[01:18:56] danielk22: stuartm: looking at the code I'm pretty sure that if that assert fails we're in deep trouble because it means we've read past the end of the buffer.
[01:22:28] danielk22: stuartm: The allocated size will often be larger than the actual size so we won't necessarily segfault if the assert is compiled out, but it's still a bug that needs fixing.
[01:24:28] danielk22: kisak: ^^^ I'd be interested in a short sample that triggers the assert...
[01:25:29] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[01:41:17] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[01:53:27] kisak: danielk22: the easiest way for me to produce a sample would be to run the frontend until it dies with that error
[01:53:56] kisak: how would I then cut off the end of that file
[01:54:26] kisak: I haven't used some binary equivilent to tail
[01:54:42] kisak: (and how much would you like?
[01:55:32] kisak: *)
[02:01:01] MavT (MavT! has joined #mythtv
[02:02:41] mrand (mrand!~mrand@ubuntu/member/mrand) has quit (Ping timeout: 240 seconds)
[02:03:50] MaverickTech (MaverickTech! has quit (Ping timeout: 260 seconds)
[02:09:28] dblain (dblain! has joined #mythtv
[02:09:30] dblain (dblain! has quit (Changing host)
[02:09:30] dblain (dblain!~dblain@mythtv/developer/dblain) has joined #mythtv
[02:10:45] mrand (mrand!~mrand@ubuntu/member/mrand) has joined #mythtv
[02:16:08] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[02:24:50] dblain (dblain!~dblain@mythtv/developer/dblain) has quit (Read error: Connection reset by peer)
[02:53:56] xris: iamlindoro: oh, lovely, didn't realize that was wikipedia. how odd.
[03:00:36] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[03:03:40] taylorr: markk: looking into the pauses some more... it seems to be caused by ffmpeg taking too long to complete av_read_frame which will call the demuxer's read_packet if no packets are available – when the demuxer calls read_packet it will buffer quite a large number of packets – during this time the decoder is stuck and doesn't provide any more frames to the video buffers which dries up and causes us to pause playback
[03:05:19] taylorr: it's very apparent with one Matroska video I have – it will read upto 20 seconds worth of packets in one av_read_frame call which basically empties the readahead buffer and causes Myth to add a large amount of new data
[03:06:12] taylorr: I play the same video under mplayer and see the same network activity bahaviour but it doesn't have any issues
[03:06:30] taylorr: wondering if we can force us to buffer more frames before starting playback
[03:06:50] taylorr: that would give us more cushion against these storms of network activity
[03:39:41] taylorr: markk: got it figured out (I think :) – made a some changes and no more stuttering
[03:44:07] taylorr: looks like because ffmpeg demuxing is infrequent/bursty that we need sufficient video buffers to survive the decoder stall
[03:46:14] taylorr: so your optimizations to automatically set the number of VDPAU buffers to a potentially smaller number will have a negative effect since the fewer number of buffers reduces the ability to survive decoder or any other type of system stalls
[03:48:49] markk: taylorr: so what changes did you make? If this is with matroska, I'm wondering whether it's the same issue I see with dvd playback – random file accesses are making reads very slow. I can't remember what the matroska file structure is though.
[03:49:01] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[03:50:09] taylorr: I increased the number of VDPAU buffers from 20 to 32
[03:51:12] taylorr: it was taking approx 300 msec for the matroska read_packet function to complete which blocked the decoder from feeding VDPAU any more video packet (and audio packets too)
[03:51:59] taylorr: so if I'm playing a 60 fps video you have to have at least 20 video buffers to survive a 300+ msec stall
[03:52:34] taylorr: I also played with vbuffers.Init() in videoout_vdpau.cpp
[03:52:49] taylorr: but it seems the number of total buffers was key
[03:53:06] taylorr: markk: are you using VDPAU for DVD playback?
[03:57:10] taylorr: markk: I haven't checked if 300 msec is excessive or not – matroska demuxed will sometimes parse 20+ seconds worth of video at a time
[03:57:47] taylorr: it may be that it drains data faster than the readahead can fill and gets blocked waiting for the backend to send more data
[04:00:42] taylorr: sphery, jpabq: for your VDPAU setup are you overriding the number of vdpau buffers to something more than 17?
[04:03:18] sphery: taylorr: no, the only modification I have to current 0.24-fixes is to set that one variable to KB512 (and was planning to back out that change since it's not fixing the issue)
[04:13:27] taylorr: sphery: could you try adding videobuffersize=32 to the filter section of your video profile and see if it helps the VDPAU specific pauses?
[04:14:04] taylorr: err, vdpaubuffersize=32
[04:18:27] sphery: taylorr: sure, I'll try that--probably tomorrow (since it will require watching a show to find one that does the vdpau pauses and then testing that setting)
[04:38:56] markk: taylorr: I'm not sure we've root caused this yet. bumping up the number of video buffers to account for network issues isn't the right approach – that's what the ringbuffer code is for.
[04:40:41] taylorr: markk: I agree, or maybe ffmpeg changed
[04:41:28] taylorr: markk: maybe the locking between the write and read to the ringbuffer has some contention or something
[04:42:20] taylorr: and I can't be for certain the one video that exhibits the issue very easily didn't have the same issue with 0.23-fixes because I didn't have the video back then
[04:52:47] kisak: danielk22: the smallest I could make it while still being a reliable testcase was 2 minutes long, about 210MB
[05:11:35] andreax (andreax! has quit (Read error: Connection reset by peer)
[05:18:24] ischyrus (ischyrus! has joined #mythtv
[06:14:20] martin___ (martin___! has joined #mythtv
[06:16:08] natanojl (natanojl! has joined #mythtv
[06:28:25] natanojl (natanojl! has quit (Ping timeout: 258 seconds)
[07:13:33] kth (kth!~kth@unaffiliated/kth) has joined #mythtv
[07:23:24] simonckenyon (simonckenyon!~simoncken@ has joined #mythtv
[07:48:57] MaverickTech (MaverickTech! has joined #mythtv
[07:49:27] MavT (MavT! has quit (Ping timeout: 252 seconds)
[08:01:56] MaverickTech (MaverickTech! has quit (Ping timeout: 276 seconds)
[08:08:56] len (len! has quit (Read error: Connection reset by peer)
[08:09:04] MaverickTech (MaverickTech! has joined #mythtv
[08:19:41] stuartm: danielk22: if that's the case, why do the lines immediately following the assert appear to handle the >= case? It would seem impossible to reach that code because of the assert?
[08:31:50] NightMonkey (NightMonkey!debian-tor@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!)
[08:54:06] ischyrus (ischyrus! has quit (Quit: Computer has gone to sleep.)
[09:26:01] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Read error: Connection reset by peer)
[09:27:32] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[10:05:03] 14WABAJ4J (14WABAJ4J! has quit (Remote host closed the connection)
[10:05:50] mike (mike! has joined #mythtv
[10:06:16] mike is now known as Guest84520
[11:46:51] gigem_ (gigem_!~david@mythtv/developer/gigem) has quit (Remote host closed the connection)
[11:47:20] gigem_ (gigem_!~david@mythtv/developer/gigem) has joined #mythtv
[12:34:11] danielk22: stuartm: asserts disappear when you compile for release... I try to write code that won't blow up easily.
[12:35:32] danielk22: stuartm: it appears handle_cc_c1 needs to have code added to abort properly when (i >= blk_size)
[12:42:07] danielk22: markk: Did you have time to test that hdhr patch? I may just apply it without hearing back from you today after a self-review, but it would of course be better to have it HDHR DVB-T tested first..
[12:46:49] PointyPumper (PointyPumper!~pintlezz@ has quit (Ping timeout: 252 seconds)
[12:48:40] danielk22: kisak: thanks, got it.
[12:50:57] dblain (dblain! has joined #mythtv
[12:50:58] dblain (dblain! has quit (Changing host)
[12:50:58] dblain (dblain!~dblain@mythtv/developer/dblain) has joined #mythtv
[12:53:09] dblain (dblain!~dblain@mythtv/developer/dblain) has quit (Client Quit)
[12:53:48] PointyPumper (PointyPumper!~pintlezz@ has joined #mythtv
[13:14:42] markk: danielk22: sorry – I meant to test it today but life got in the way... I'm planning on testing in the morning but if you're happy – go for it.
[13:15:36] stuarta: anyway one of us european devs can get hold of dvb-t hdhr?
[13:16:14] taylorr: markk: what is the minimum amount of video buffers that can be chosed with the new VDPAU dynamic buffer code?
[13:19:51] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[13:20:44] danielk22: stuarta: send me your address out of band and I'll ping nick for an engineering sample...
[13:21:38] markk: taylorr: the code starts with the number of reference frames (which will default to a minimum of 2 and has a maximum of 16) and add a default of 12 extra frames on top. the vdpaubuffersize option will adjust the 12 value to between 6 and 50 – so the default minimum is 14 and the absolute minimum is 8.
[13:22:08] markk: and an absolute max of 66 :)
[13:24:01] stuarta: danielk22: pm okay or you prefer an email?
[13:25:12] taylorr: markk: under what scenario could it be 8?
[13:26:04] dblain (dblain! has joined #mythtv
[13:26:05] dblain (dblain! has quit (Changing host)
[13:26:05] dblain (dblain!~dblain@mythtv/developer/dblain) has joined #mythtv
[13:27:18] taylorr: markk: nm, I see how it would be 8
[13:36:00] Jordack (Jordack! has joined #mythtv
[13:36:33] dblain (dblain!~dblain@mythtv/developer/dblain) has quit (Read error: Connection reset by peer)
[13:40:59] danielk22: markk: I'm fairly certain of the db updates, less so of the tuning code, but I can always make another commit.
[13:50:55] j-rod|afk is now known as j-rod
[14:06:44] danielk22: markk: <-- this one is a bit more clever and doesn't use auto when we can disambiguate the tuner type using the modulation..
[14:07:12] martin___ (martin___! has quit (Remote host closed the connection)
[14:11:44] kth1 (kth1! has joined #mythtv
[14:14:31] kth (kth!~kth@unaffiliated/kth) has quit (Ping timeout: 252 seconds)
[14:27:48] wagnerrp (wagnerrp!~wagnerrp_@mythtv/developer/wagnerrp) has quit (Read error: Operation timed out)
[14:31:38] wagnerrp (wagnerrp!~wagnerrp_@mythtv/developer/wagnerrp) has joined #mythtv
[14:33:21] markk: danielk22: thanks – I'll give it a run in the morning (around 10 hours or so!)
[14:49:26] kth1 (kth1! has quit (Quit: Leaving.)
[14:52:01] wagnerrp (wagnerrp!~wagnerrp_@mythtv/developer/wagnerrp) has quit (Ping timeout: 264 seconds)
[14:53:17] wagnerrp (wagnerrp!~wagnerrp_@mythtv/developer/wagnerrp) has joined #mythtv
[14:54:41] iamlindoro: This kernel 2.6.38 think in .24 is really getting to be a mess
[14:55:16] iamlindoro: Everyone is upgrading to Ubuntu 11/04/Fedora 15/etc. and trying to use patches that appear to be half-fixes, and then running into issues
[14:56:08] iamlindoro: and then to add fuel to the fire, they're making a mess of trying to downgrade, still running into the problem (likely due to failing to recompile myth or failing to install downgraded kernel headers) and spreading misinformation on the mailing list that it's *not* a kernel 2.6.38 issue, even though it is
[14:57:14] ** stuarta goes huh?!?!? **
[14:57:36] iamlindoro: stuarta: ?
[14:57:48] stuarta: i'm trying to make sense of what you just wrote...
[14:57:58] iamlindoro: stuarta: Are you following the mailing list and trac tickets?
[14:58:14] stuarta: i'm rather behind :(
[14:58:20] stuarta: and not on -users
[14:58:38] stuarta: 1463 unread mythtv emails...
[14:58:40] wagnerrp: 2.6.38 removed v4l1, which broke analog capture in mythtv
[14:58:45] iamlindoro: Kernel 2.6.38 removes v4l1 support. Most of the current distros are now puching 2.6.38. Trying to compile myth against it disables v4l and ivtv
[14:58:45] stuarta: ah yes.
[14:59:08] stuarta: shouldn't be too hard to retrofit a patch
[14:59:10] wagnerrp: mythbuntu has a patch against it that fixes analog capture, but breaks other things like hdpvr capture
[14:59:12] iamlindoro: So there are various patches not by us being employed, each of which appears to be at least subtly flawed
[14:59:32] iamlindoro: So that's problem a
[14:59:59] iamlindoro: problem b is that users are making a mess of trying to downgrade, resulting in still running into the problem for one of a variety of reasons, and then muddying the water by claiming it's *not* a kernel 2.6.38 issue
[15:00:30] stuarta: bloody users. :)
[15:00:49] abqjp (abqjp! has quit (Quit: abqjp)
[15:04:52] danielk22: iamlindoro: I think the stuff I wrote last week should be mostly backportable; but for fixes it may be easier just to re-instate myth_videodev.h ... or whatever we called our local copy before we foolishly trusted the distro's to maintain those headers.
[15:04:57] iamlindoro: Tough to blame them, It's fair to assume that things like that will just go on working... it's the frantic hindering of troubleshooting that is more bothersome
[15:05:29] iamlindoro: danielk22: Yeah, I meant to try to look at doing a backport this weekend but just ran out of time and didn't manage to look at the computer at all
[15:12:04] abqjp (abqjp!~abqjp@ has joined #mythtv
[15:15:14] sphery: danielk22: [24892] is the commit that removed the V4L headers
[15:15:14] MythLogBot: SVN 24892: (branch master)
[15:20:16] ** stuarta pats the bot **
[15:28:19] danielk22: that patch does a lot more than just remove those headers...
[15:29:36] sphery: taylorr: BTW, this morning I realized why I was having such a hard time finding a recording that exhibited the playback pause problem last night. Before my trip, I had decided that they were getting too annoying and--based on what you had said/found--decided to switch to ffmpeg decode with VDPAU rendering, and I haven't seen a pause since then (other than the at-recording-start/stop pauses). I'll swap back to my vdpau-decode playback profile ...
[15:29:42] sphery: ... tonight and try out the vdpaubuffersize you mentioned.
[15:29:47] tgm4883: I tried backporting that V4L2 patch for 2.6.38 from master to 0.24 over the weekend, but I only know python and wasn't 100% sure I was doing it right. In the end, the patch didn't apply to our (mythbuntu) builds successfully but I think that was more due to me creating the patch using upstream source
[15:30:16] tgm4883: Just in case anyone wants to tell me to stay far away from things not python, the patch I did is here . . . 2.6.38.patch
[15:30:27] sphery: danielk22: how difficult would it be to remove the extra junk?
[15:31:56] tgm4883: basically all I did was take danielk22 patch and find the relative locations in 0.24.1 code
[15:32:51] danielk22: sphery: I think it might be easiest just to grab the videodev_myth.h from the previous revision, then replace all occurances of videodev.h with videodev_myth.h, and finally remove all reference to videodev.h in the configure script.
[15:36:00] stoffel (stoffel! has joined #mythtv
[15:37:06] ischyrus (ischyrus! has joined #mythtv
[15:37:10] sphery: danielk22: Also, if we just add our own copies of those headers, do we know for sure that a system whose libs were build with 2.6.38 kernel headers (and has no videodev*.h in /usr/include/linux) won't have problems if we attempt to use stuff that's not actually on the system? I have to admit I have no idea how much kernel/driver interfacing we're using videodev.h for... (In other words, have we confirmed that everything works fine for a user ...
[15:37:17] sphery: ... with a system built with pre-2.6.38 headers, but running a 2.6.38 kernel?)
[15:40:49] andreax (andreax! has joined #mythtv
[15:43:21] danielk22: sphery: yeah, removed ioctls are not reused, otherwise programs compiled with earlier kernels would cause serious problems when you upgrade the kernel.
[15:43:55] sphery: great... so that sounds like a great approach, then.
[15:45:27] wagnerrp: sphery: post on the -users list seems to confirm it working for another user
[15:46:43] sphery: Ah, good--I haven't kept up with that whole thread. It was getting too hard to read (and not only because of quantity of posts :).
[15:47:42] ischyrus (ischyrus! has quit (Quit: Computer has gone to sleep.)
[15:48:59] taylorr: sphery: cool, interesting to know if it helps or not
[15:49:11] taylorr: the -users list seems to be getting restless about the problem :)
[15:49:59] sphery: heh, definitely... we'll see how much hate mail my "if you use ffmpeg decode, you won't see the pauses" post stirs up. (Though it would be interesting to test with ffmpeg decode/vdpau render, and vdpau deint)
[15:50:12] sphery: I'll try to do that, too
[15:50:38] taylorr: sphery: I don't think it's related to deinterlacing at all
[15:50:52] Goga777 (Goga777! has joined #mythtv
[15:51:37] taylorr: there seems to be two distinct issues: 1) blocking in the UI thread during qapp->processEvents() and 2) video buffer starvation while ffmpeg demuxer is buffering/reading packets internally
[15:52:06] sphery: yeah, I agree--I think it's just the decoding (but wouldn't hurt to prove that :)
[15:52:34] taylorr: I'm focusing on the second problem as I'm not the best to handle the playbackbox event processing that seems to causing the most trouble out in the wild
[15:53:22] sphery: yeah, I think 1) is the at-recording-start/stop pauses and 2) is the vdpau decode (in combination with ffmpeg demux) issue, right?
[15:53:42] sphery: where ffmpeg demux and ffmpeg decode seems fine
[15:54:11] taylorr: sphery: we have different amounts of video buffers for Xv and VDPAU video output
[15:54:24] taylorr: Xv can weather a longer storm than VDPAU
[15:54:37] sphery: well, I'm still using vdpau rendering--just using ffmpeg decode
[15:54:49] taylorr: we have a hard coded 31 video frame buffers for Xv and in 0.24-fixes it was hard coded to 17
[15:55:03] taylorr: for VDPAU
[15:55:21] taylorr: and in now in trunk VDPAU buffer size is variable
[15:55:53] taylorr: sphery: right, so when you switched to ffmpeg decode you got more video frame buffers
[15:56:03] taylorr: and the problem went away, right?
[15:56:56] kormoc is now known as kormoc_afk
[15:56:57] sphery: yeah, no problems with ffmpeg decode and vdpau render
[15:57:09] sphery: only have problems if I use vdpau decode and vdpau render
[15:57:14] taylorr: we are only at 92 replies in the "random short pauses" thread :)
[15:57:34] taylorr: sphery: so the experiment you try tonight will help clue us in
[15:58:33] sphery: heh, yeah, it's way too deep
[16:00:23] taylorr: sphery: and to be clear the UI thread blocking can be caused by any event on the backend that triggers a MythSocket call to update the playbackbox
[16:00:37] taylorr: that's why those type of pauses go away if you play via MythVideo
[16:00:45] stuartm: anyone heard rumours of whether they are working on a DVB-T2 HDHR?
[16:01:18] taylorr: sphery: so really 3 scenarios – the two I've mentioned and then 3) pauses at program change boundaries
[16:01:40] taylorr: you might want to be clear on the list about the different scenarios
[16:02:30] sphery: taylorr: yeah, and since we get several events (including recording list change, etc.) when recording starts/stops (or when recordings are deleted on other frontends), those wouldn't be affected by vdpau/ffmpeg decode... I thought those were the ones you were talking about with 1), the qapp->processEvents() ones
[16:02:56] taylorr: right, those are scenario 1
[16:03:32] taylorr: for scenario 1 it doesn't matter which decoder/output method you use and it's blocking the UI thread directly
[16:03:32] sphery: so what's 3)?
[16:03:51] taylorr: pauses in LiveTV at program change boundaries
[16:04:02] sphery: ah, livetv only... yeah, I never would have seen those :)
[16:04:08] taylorr: I only bring it up because it's been brought up in the thread
[16:04:46] taylorr: people are trying to correlate all 3 somehow and as a bonus educating us on WD hard drive performance
[16:05:02] sphery: I see. if I post more to the thread, I'll mention that. I think for now the "at-recording-start/stop pauses" is close enough of a description to let them know that some will still exist.
[16:06:14] sphery: since livetv program boundaries also fall under "recording start/stop", even if it's not 100% the same as 1), it's reasonable that people will recognize it as one that still exists after switching to ffmpeg decode
[16:06:45] sphery: btw, did you need me to try an older nvidia driver? I have an old kernel that I can use to test even old nvidia drivers.
[16:07:47] sphery: I currently have 270.41.06, and I saw that some are seeing problems on 260.x, and mar kk was using an older one that he thinks may not have the issue
[16:09:10] taylorr: sphery: I went back to 190 and it didn't help – I wouldn't bother
[16:10:18] sphery: ok, thanks--wasn't sure if anyone was able to test it (saw jp abq couldn't use the older one with his kernel)
[16:10:43] taylorr: sphery: one other thing I was trying to determine is how many VDPAU buffers are used in other apps – if I remember correctly they have a fixed high number for this which might explain why they don't have the issues
[16:11:39] taylorr: sphery: You've already confused the -users
[16:13:16] sphery: heh, I'd prefer to think of it as saying that I've failed to unconfuse -users. I'll reply, now, with the info that there are 3 distinct issues, and which the ffmpeg decode fixes.
[16:13:55] taylorr: sphery: you can also ask people to report if they are using a custom vdpaubuffersize in the filter section of the playback profiles
[16:19:18] iamlindoro: stuartm: They only just released the new model of the DVB-T tuner... I would guess it might be a bit
[16:23:56] ** stuarta ho hums **
[16:31:32] stoffel (stoffel! has quit (Ping timeout: 276 seconds)
[16:46:05] kth (kth!~kth@unaffiliated/kth) has joined #mythtv
[16:47:12] gigem_ (gigem_!~david@mythtv/developer/gigem) has quit (Remote host closed the connection)
[16:47:38] gigem_ (gigem_! has joined #mythtv
[16:47:38] gigem_ (gigem_! has quit (Changing host)
[16:47:38] gigem_ (gigem_!~david@mythtv/developer/gigem) has joined #mythtv
[16:59:40] kormoc_afk is now known as kormoc
[17:04:05] stoffel (stoffel! has joined #mythtv
[17:14:28] wagnerrp: taylorr: you might have an answer for this one
[17:14:51] wagnerrp: user on the -users list has been transcoding his recordings to divx/avi
[17:15:02] wagnerrp: and while they are all ~6mbps
[17:15:14] wagnerrp: some play fine, while some max out his wireless network at >15mbps
[17:15:23] wagnerrp: is it possible his transcodes are screwed up
[17:15:46] wagnerrp: which causes the libav decoders to bounce all over the file, resulting in inefficient network usage?
[17:16:15] wagnerrp: he claims using CIFSs instead of myth's streaming fixes the problem
[17:16:41] taylorr: wagnerrp: I've noticed that depending on the video and the demuxer used (ie, mpeg-ts, matroska) the file reading can be extremely bursty
[17:16:42] wagnerrp: which would make sense if linux is using his memory buffer to prevent having to pull information multiple times as it jumps around
[17:18:21] taylorr: for example, the mastroska demuxer does a cluster read of many seconds worth of packets at one time which is buffered inside ffmpeg – so for however many of seconds of packets get read you will see no network activity until it runs out
[17:19:01] Beirdo: 2011-05–23 03:00:03.165918 [8590] thread_unknown v4lrecorder.cpp:124 (OpenVBIDe
[17:19:01] MythLogBot: SVN 8590: (branch master)
[17:19:01] Beirdo: vice) – V4LRec(33:/dev/video-hvr0) Error: Can't open vbi device: ''
[17:19:03] taylorr: so, yes, network spikes could occur and depending on how many video buffers are used will determine if playback is affected
[17:19:32] wagnerrp: i have noticed that, but i always assumed it was an artifact of ifstat
[17:19:33] Beirdo: danielk22: your new v4lrecorder (or someone else's changes) seems to have broken HVR2250 analog recording)
[17:19:42] wagnerrp: rather than something that was actually happening
[17:20:25] Beirdo: is vbi supposed to work on them now? I had an exception in there to not even try
[17:21:08] taylorr: wagnerrp: no, it is really happening
[17:21:40] taylorr: which is why we need plentiful amounts of buffering all over the place
[17:22:32] taylorr: I was hoping that the readahead buffering would compensate but it doesn't seem to help for this specific problem
[17:23:12] taylorr: we only have 4 MByte readahead ringbuffer so a demuxer could easily drain it during a cluster read
[17:24:00] taylorr: but I think the real expense is the demuxing/parsing/copying of the stream
[17:24:01] Beirdo: gonna try enabling VBI on it and see if it's still borked
[17:25:30] Beirdo: OK, seems to be behaving so far. :)
[17:25:38] Beirdo: time to go interview someone.
[17:28:49] taylorr: Beirdo: ask the candidate how to fix playback pauses in MythTv and hire him if he has the answer
[17:44:31] wagnerrp: taylorr: well thats only if we want to support remote operation over old slow wireless
[17:44:41] wagnerrp: up until now, weve just been saying run wires and be done with it
[18:00:43] j-rod (j-rod! has quit (Quit: Coyote finally caught me)
[18:02:16] j-rod|afk (j-rod|afk! has joined #mythtv
[18:02:22] j-rod|afk is now known as j-rod
[18:05:56] taylorr: wagnerrp: well, I think this new knowledge might explain why wireless was so hit or miss even though it seemed like it had the necessary bandwidth
[18:08:58] j-rod (j-rod! has quit (Quit: Coyote finally caught me)
[18:10:21] j-rod|afk (j-rod|afk! has joined #mythtv
[18:10:26] j-rod|afk is now known as j-rod
[18:12:17] stoffel (stoffel! has quit (Remote host closed the connection)
[18:13:03] noahric_ (noahric_!4a7d3b41@gateway/web/freenode/ip. has joined #mythtv
[18:17:40] danielk22: Beirdo: It reads the VBI now, but doesn't write it out. Are you using drivers that don't have VBI support?
[18:20:59] Goga777 (Goga777! has quit (Read error: Operation timed out)
[18:24:14] slipcon (slipcon! has joined #mythtv
[18:25:50] stuartm:
[18:26:48] NightMonkey (NightMonkey!debian-tor@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[18:34:08] tris (tris! has quit (Excess Flood)
[18:37:55] tris (tris! has joined #mythtv
[18:37:55] zombor_ (zombor_!~zombor_@kohana/developer/zombor) has joined #mythtv
[18:41:11] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Ping timeout: 240 seconds)
[18:43:52] Beirdo: danielk22: the problem with the hvr2250 is that it's a DVB driver, but uses V4L-style VBI
[18:44:37] Beirdo: something that changed recently makes it try to open the VBI device, whereas before we ignored it if it was the 2250 as it wasn't working at that time
[18:45:04] Beirdo: I put in the VBI devices, and it has been recording, and when I get home,I'll see if the VBI actually worked too :)
[18:45:19] kth (kth!~kth@unaffiliated/kth) has quit (Quit: Leaving.)
[18:45:47] Beirdo: but at least it's recording. I call it a win, just for those using the 2250, they need to be sure to setup the VBI device now, or it will zero-byte the recordings when it fails the VBI open.
[18:48:15] Beirdo: no, it's still failing. crap
[18:48:40] Beirdo: I'll dig into it tonight when I'm by the box
[18:48:52] Beirdo: 2011-05–23 11:48:07.122309 MPEGRec(/dev/video-hvr0) Error: StartEncoding failed eno: Invalid argument (22)
[18:55:39] abqjp: taylorr: I will be available this evening if you need me to try anything.
[18:57:21] abqjp: I used to set the vdpau buffers, but removed that setting when mark made it dynamic. If I remember right, I was experiencing pauses even with it hard-coded, but I don't remember what I had it hard-coded to.
[18:58:31] sphery: FWIW, a couple replies on list seem to indicate users are still seeing the issue with vdpaubuffersize=32 set
[19:04:22] wylie (wylie! has joined #mythtv
[19:10:02] danielk22: Beirdo: Ok, we should still record if the VBI device isn't there. But what drivers are you using? I thought the VBI driver went in last summer...
[19:11:09] Jordack (Jordack! has quit ()
[19:11:37] taylorr: sphery: but which pauses are they seeing :)
[19:13:24] sphery: heh, I /hope/ they now know enough to notice which are which
[19:14:04] taylorr: sphery: I never trust anything posted on the -users list
[19:14:08] zombor_ (zombor_!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[19:14:12] Beirdo: the VBI is in there, but it's not normal for a DVB device, it's more like the PVR250, IIRC
[19:14:32] Beirdo: I will have to toy with it and get it to behave tonight :)
[19:14:33] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[19:15:31] Beirdo: for now, I'm going to disable VBI again for saa7164 on my local copy so any recordings will work until I get home
[19:17:38] danielk22: Beirdo: I tested with a HVR-2250 analog recording and saw real honest to goodness VBI data.. I even decoded some of it, and you'll see it if you record analog recording with 608 captions and run with "-v vbi" I was using the drivers from stoth... but that was last summer, I assumed those were integrated into the kernel proper long ago.
[19:18:40] danielk22: Beirdo: I don't use it day-to-day, so I don't know if the code atrophied or if we just don't support the particular driver you are using..
[19:19:06] Beirdo: the driver I'm using is the one that got merged into the kernel
[19:19:20] Beirdo: just before it was merged :)
[19:19:40] Beirdo: but yeah, I'll take a look tonight, there's probably something silly going on there
[19:19:55] danielk22: The question is was this this pre-or-post august/sept 2010?
[19:20:00] Beirdo: glad to hear you have working
[19:20:06] Beirdo: post, I believe
[19:20:20] danielk22: then it should have vbi support... me thinks..
[19:20:21] Beirdo: let me see, one sec
[19:20:44] Beirdo: end of September
[19:21:32] Beirdo: there is VBI there, but it's refusing to behave at the exact second. Nothing an hour or two fo debugging likely can't fix
[19:23:08] sphery: danielk22: since I just pushed a DB update patch and you had one in the works, I updated yours for the new version info: . It's an update of the last one you gave mar kk (the one at ).
[19:24:13] danielk22: Beirdo: "uname -a" ?
[19:24:32] Beirdo: Linux mythbe 2.6.34-rc1-jarod1 #6 SMP Sun Jul 4 14:59:12 PDT 2010 x86_64 GNU/Linux
[19:24:36] Beirdo: irrelevant
[19:24:46] Beirdo: :)
[19:25:06] Beirdo: actually, probably not
[19:28:05] Beirdo: it's failing out on the ioctl VIDIOC_ENCODER_CMD, it seems
[19:29:13] danielk22: hmm, so then it's not really a vbi thing... please pastebin the -v record,channel logs..
[19:29:25] andreax (andreax! has quit (Ping timeout: 252 seconds)
[19:30:13] andreax (andreax! has joined #mythtv
[19:32:14] Beirdo:
[19:32:24] Beirdo: that's what it said on the last failure
[19:32:47] Beirdo: it's actually recording right now on another source, so I can't easily change the log level
[19:33:35] danielk22: "mythbackend --setverbose channel,record" <-- but it won't really help until the next record..
[19:34:59] Beirdo: oh pretty, another coredump to fix :)
[19:35:07] Beirdo: OK, let me start another recording
[19:36:18] Beirdo: ARGH
[19:36:28] Beirdo: I said to use the 2250, stupid machine
[19:37:19] danielk22: Beirdo: you're using the card for both DVB and analog?
[19:37:28] Beirdo: yes.
[19:37:49] Beirdo: OK, I'm a tard... I told it the DVB side :)
[19:38:07] Beirdo: however, it went to the analog side anyways.
[19:39:16] Beirdo:
[19:39:25] Beirdo: as the channel isn't on the DVB side (OTA)
[19:41:01] danielk22: Ok, because that command should only fail when the card is in already use. Can you try removing the DVB usage of the card for a sec and seeing if that resolves the problem on the analog side?
[19:41:20] Beirdo: nothing is recording on the DVB side
[19:42:13] Beirdo: but let me tell it to use the analog side...
[19:42:20] Beirdo: may just be my retardedness
[19:42:29] Beirdo: nope, same thing
[19:43:39] danielk22: Right, but is the radio tuned due to the initial tuning on the DVB side, or is the problem caused by the analog signal monitor. To test you need to remove the dvb card definition from the db, stop the backend, wait 5 seconds and then restart the backend.
[19:45:33] danielk22: A few years back the DVB devs added some code to keep the dvb tuner reserved for a few seconds after last usage so that many apps strung back-to-back didn't require re-tuning, but this means that when you switch from one side of the card to the other side it sometimes behaves badly.
[19:45:52] Beirdo: it has never done this before
[19:46:15] Beirdo: and my driver hasn't changed since September :)
[19:46:27] Beirdo: but... let me try something here
[19:47:56] Beirdo: unloaded and reloaded the driver
[19:51:11] zombor_ (zombor_!~zombor_@kohana/developer/zombor) has joined #mythtv
[19:54:32] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Ping timeout: 240 seconds)
[19:54:57] danielk22: Beirdo: btw i'm not suggesting this as a solution, just trying to isolate the problem
[19:55:24] Beirdo: yeah, just hard to do while my box is doing live recordings :)
[19:58:22] Beirdo: be a lot nicer if there was a "disable this card" without deleting
[19:58:33] Beirdo: it is not fun ripping crap out ;)
[19:58:54] Beirdo: Oooh, I can make em fail
[19:59:31] Beirdo: put em on adapter2 and adapter3 which don't exist
[20:02:29] natanojl (natanojl! has joined #mythtv
[20:02:49] iamlindoro: Beirdo: just remove the video source from the input, voila, it's disabled
[20:12:01] iamlindoro: stuartm: I think the fillperiod will also need to be removed from the web settings xml
[20:13:10] iamlindoro: stuartm: programs/mythbackend/config_backend_general.xml
[20:18:12] stuartm: ah, wonder why my grep missed that
[20:18:14] stuartm: thanks
[20:26:15] Beirdo: danielk22: found the offending line of code
[20:26:44] Beirdo: mpegrecorder.cpp:972
[20:27:29] Beirdo: it used to be if(requires_special_pause && !StartEncoding(readfd))
[20:27:45] Beirdo: now it's just: if(!StartEncoding(readfd))
[20:28:07] Beirdo: and in the old code, the hvr2250 would have requires_special_pause being false
[20:28:18] Beirdo: I put an && 0 in there, and it's recording
[20:33:26] fp__ (fp__!~fp@ has joined #mythtv
[20:44:04] zombor_ (zombor_!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[20:49:41] iamlindoro (iamlindoro!~iamlindor@mythtv/developer/iamlindoro) has quit (Ping timeout: 240 seconds)
[20:51:11] fp__ (fp__!~fp@ has quit (Ping timeout: 250 seconds)
[20:51:32] iamlindoro (iamlindoro!~iamlindor@mythtv/developer/iamlindoro) has joined #mythtv
[20:56:13] Beirdo: actually, I put 0 &&
[20:56:17] Beirdo: to be precise :)
[20:56:26] Beirdo: I'm gonna go get lunch
[20:58:49] len (len! has joined #mythtv
[20:59:11] fp__ (fp__!~fp@ has joined #mythtv
[20:59:41] natanojl (natanojl! has quit (Ping timeout: 240 seconds)
[21:00:03] JEDIDIAH__ (JEDIDIAH__! has joined #mythtv
[21:06:04] danielk22: Beirdo: *sigh* That change was made based on a V4L dev saying all the device need that start/stop encoding code now... (since the latest ivtv and all hvr-1600 drivers require it.)
[21:07:38] danielk22: Beirdo: still you can do that test with the dvb portion disabled that should help; i didn't see this problem in testing...
[21:08:26] fp__ (fp__!~fp@ has quit (Ping timeout: 276 seconds)
[21:13:52] Beirdo: yeah, I'll give it a shot in a bit
[21:17:52] slipcon (slipcon! has quit (Quit: Leaving.)
[21:18:17] Beirdo: Hmm, maybe we could make it try anyways, I'm sure that there are old drivers still in use, and we will get a lot of complaints about mythtv being suddenly broken.
[21:23:48] Beirdo: I'm pretty sure that there's no need for the start encoding code at all
[21:24:09] Beirdo: otherwise cat /dev/videoX > blah.mpg wouldn't work
[21:24:25] Beirdo: I'm pretty sure that cat does not send that ioctl
[21:26:08] Beirdo: now, for non-hardware encoders... no clue. :)
[21:26:52] Beirdo: but I'll give it a shot tonight when I'm home... with removing the DVB devices (after taking a dump of hte table)
[21:29:43] mrand (mrand!~mrand@ubuntu/member/mrand) has quit (Ping timeout: 246 seconds)
[21:31:24] danielk22: Beirdo: It's required if you change encoding parameters or change the channel, which we want to be able to do..
[21:32:03] Beirdo: heh, fair enough :)
[21:32:15] Beirdo: that we definitely wanna be able to do
[21:33:20] Beirdo: is that only for cards with streaming ability?
[21:34:12] mrand (mrand!~mrand@ubuntu/member/mrand) has joined #mythtv
[21:37:14] Beirdo: looking at the saa7164 driver in the media_tree as going into 2.6.39, it doesn't support that ioctl at all
[21:37:48] Beirdo: whereas the ivtv in the same tree does
[21:45:21] Beirdo: hmm, looking at the V4L2 API spec... it's experimental, and a start is not technically required as a read is supposed to do a start if it's not started yet
[21:45:38] danielk22: Beirdo: This is not the STREAMON ioctl it's the V4L2_ENC_CMD_START VIDIOC_ENCODER_CMD command. AFAIK It should be supported by all cards that have a build in encoder, but possibly not supported by simple frame grabbers.
[21:46:09] Beirdo:
[21:46:43] danielk22: right, we can drop HDPVR and HVR support until it becomes official, but i think that would cause user revolt ;]
[21:46:50] Beirdo: I think we should just take the EINVAL and log it and carry on, no aborting
[21:47:06] Beirdo: it's a lot more than just those :)
[21:47:49] Beirdo: but anyways, if as the spec says, read() will call that, I think that an EINVAL on there shouldn't actually hurt anything
[21:47:51] danielk22: that's a possible solution, make it a warning.. but i want to understand this problem first, it may be a symptom of something more serious..
[21:48:37] danielk22: Beirdo: right it's the CMD_STOP that's the important one.. otherwise we need to close all FD's which mean a major architectural change, i.e. disable hdpvr & hvr support...
[21:48:40] Beirdo: I think it's a symptom of an experimental part of the V4L2 spec becoming "required" by a subset of the authors, and no update to the spec yet, or something.
[21:48:43] Beirdo: Yeah
[21:49:18] Beirdo: but aborting our recording on a failed stop... would still work for recordings fine.
[21:49:25] Beirdo: just maybe not for LiveETV
[21:49:31] Beirdo: er LiveTV
[21:50:18] Beirdo: I mean, we're trying to stop anyways :)
[21:51:30] fp__ (fp__!~fp@ has joined #mythtv
[21:52:42] danielk22: Prolly livetv and channel switching will work for drivers that ignore cmd_stop. We really gotta make mythtv easy enough to install that all the driver writers use it to test their drivers ;] But I tested the HVR-2250 so I really think there is something else going on.
[21:53:03] Beirdo: which exact version do you have?
[21:53:55] Beirdo: hmmm, not sure if that srcversion in modinfo is even useful
[21:54:58] danielk22: parent: 15042:8da3bd06a289 tip
[21:55:30] Beirdo: what's that from (so I can try to corrolate here)
[21:56:41] danielk22: "Wed Oct 06 20:52:22 2010 -0400" It's from the v4l tree.
[21:56:52] Beirdo: OK
[21:57:42] Beirdo: well, mine corresponds to the last of my commits on the driver
[21:58:06] Beirdo: which at integration time was 2010-10–21, but I actually made the changes earlier
[21:58:42] danielk22: Beirdo: It looks like you made a commit Sept 30th, 2010 which got the VBI working. And stoth made another commit a couple days later which got the driver to work in a general framework (got rid of the false flag V4L2_CAP_STREAMING).
[21:59:10] Beirdo: yeah, which is why I was asking if it was related to that
[21:59:23] danielk22: Once everything was working It looks like I stopped updating ;)
[21:59:43] Beirdo: once it worked for me, so did I ;)
[22:01:05] j-rod is now known as j-rod|afk
[22:01:16] danielk22: Heh, so maybe you're just 7 days behind the fixed driver ;]
[22:01:42] Beirdo: could be, but do we even look at the V4L2_CAP_STREAMING?
[22:01:51] danielk22: If the false flag is the problem and it made it into mainline, I can easily fix that.
[22:02:30] Beirdo: oooh, you did add capability checking...
[22:03:14] Beirdo: I don't see how it would be affecting this though
[22:03:35] Beirdo: it's just this driver doesn't support the encoder start/stop ioctl
[22:03:45] Beirdo: and now we expect them all to
[22:04:01] danielk22: yup, that capability is what determines whether we call VIDIOC_STREAMOFF.. but that's not the error you're seeing...
[22:04:14] Beirdo: so, two ways to fix it... make it a warning... or work with stoth to add it :)
[22:04:32] Beirdo: well, two simple ways for THIS card anyways :)
[22:06:52] Beirdo: it likely wouldn't take much to get it to honor the ioctl (and do squat with it)
[22:07:34] Beirdo: now why it works for you, I have no clue
[22:07:47] danielk22: I think maybe just making it a warning may work.. annoying that some cards work and others do not.
[22:07:49] Beirdo: it should always return EINVAL as it doesn't support the ioctl at all
[22:08:36] Beirdo: yeah, I'll test with the return of StartEncoding changed from return false;
[22:08:45] Beirdo: to return (errno == EINVAL);
[22:08:51] danielk22: to restate, annoying that some cards _require_ an optional API call..
[22:08:56] Beirdo: yeah
[22:09:00] Beirdo: and some don't
[22:09:09] Beirdo: that is annoying
[22:09:52] ybot (ybot!~quassel@ has quit (Remote host closed the connection)
[22:10:37] danielk22: Might be nice to add the ioctl to the driver though, if only for the stop on GOP vs stop immediately capability.
[22:11:38] Beirdo: yeah, the stop on GOP would need a bit of work to support properly, I'd bet, but it would be nice
[22:11:46] Beirdo:
[22:11:48] Beirdo: there.
[22:12:03] danielk22: Beirdo: it's possible I made some changes to the code since I did the HVR testing.
[22:12:12] Beirdo: it whines (even says error) and carries on anyways as it's EINVAL
[22:12:22] Beirdo: ahhh, that is a possibility :)
[22:12:43] Beirdo: I do like it with fewer assumptions though :)
[22:13:14] Beirdo: the parts where you have driver.left(7) == "saa7164", I don't think you need the .left(7)
[22:13:40] Beirdo: as when it fills out the driver, I put in a regexp to strip off the [0] and [1]
[22:13:40] MythLogBot: No match for SVN revision 0
[22:13:40] MythLogBot: SVN 1: (branch master)
[22:13:59] ** Beirdo slaps MythLogBot. Stop being useful at the wrong time :) **
[22:16:37] danielk22: Beirdo: Hmm, I don't really like changing the result of the driver query.. but then again that cruft doesn't really belong there.
[22:17:31] Beirdo: yeah, I know. but having to do the .left() over and over just to strip off [xxx] is annoying too
[22:17:47] danielk22: yep
[22:18:00] Beirdo: but... not like we do it thousands of times... 6 of one, half a dozen of the other
[22:19:02] Beirdo: And I think your improved VBI code does seem to get VBI on the 2250 :) Gotta go home and see if it's useful or not for those recordings
[22:19:16] Beirdo: just need it on HDPVR now (yeah, like that's even possible)
[22:19:48] danielk22: Beirdo: Pretty sure it's not useful right now.. but it wouldn't be hard to write out an srt file...
[22:19:57] Beirdo: argh. seems that previews are half-borked now too.
[22:20:07] Beirdo: for my mpeg2 recordings only
[22:20:18] Beirdo: I guess I get to go searching through that code again
[22:21:16] Beirdo: wait a minute. The concert (off the HDPVR) this morning says CC.
[22:21:53] ** Beirdo shrugs **
[22:46:23] chris_k (chris_k! has joined #mythtv
[22:47:06] kormoc is now known as kormoc_afk
[22:58:53] chris_k (chris_k! has left #mythtv ()
[23:01:35] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[23:45:51] abqjp (abqjp!~abqjp@ has quit (Quit: abqjp)

IRC Logs collected by BeirdoBot.
Please use the above link to report any bugs.