| Monday, May 23rd, 2011, 13:21 UTC | ||
| [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!~dblain@c-76-127-227-175.hsd1.ma.comcast.net) has joined #mythtv | |
| [13:26:05] | dblain (dblain!~dblain@c-76-127-227-175.hsd1.ma.comcast.net) 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!~jordack@h69-131-44-221.mdsnwi.tisp.static.tds.net) 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: http://pastebin.ca/2067647 <-- 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___!~quassel@static-88.131.29.2.addr.tdcsong.se) has quit (Remote host closed the connection) | |
| [14:11:44] | kth1 (kth1!~kth@dyndsl-085-016-238-235.ewe-ip-backbone.de) 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!~kth@dyndsl-085-016-238-235.ewe-ip-backbone.de) 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!~abqjp@174-28-187-116.albq.qwest.net) 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@97.119.171.42) 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) https://github.com/MythTV/mythtv/commit/bf7225c7 |
| [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 http://bazaar.launchpad.net/~tgm4883/mythtv/m . . . 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!~quassel@p57B4CF37.dip.t-dialin.net) has joined #mythtv | |
| [15:37:06] | ischyrus (ischyrus!~ischyrus@50-46-219-217.evrt.wa.frontiernet.net) 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!~andreaz@p57B93882.dip.t-dialin.net) 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!~ischyrus@50-46-219-217.evrt.wa.frontiernet.net) 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!~Goga777@shpd-95-53-220-29.vologda.ru) 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!~quassel@p57B4CF37.dip.t-dialin.net) 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_!~david@host103.16.intrusion.com) has joined #mythtv | |
| [16:47:38] | gigem_ (gigem_!~david@host103.16.intrusion.com) 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!~quassel@p57B4CF37.dip.t-dialin.net) 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) https://github.com/MythTV/mythtv/commit/26eedbf5 |
| [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!~jarod@static-72-93-233-3.bstnma.fios.verizon.net) has quit (Quit: Coyote finally caught me) | |
| [18:02:16] | j-rod|afk (j-rod|afk!~jarod@static-72-93-233-3.bstnma.fios.verizon.net) 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!~jarod@static-72-93-233-3.bstnma.fios.verizon.net) has quit (Quit: Coyote finally caught me) | |
| [18:10:21] | j-rod|afk (j-rod|afk!~jarod@static-72-93-233-3.bstnma.fios.verizon.net) has joined #mythtv | |
| [18:10:26] | j-rod|afk is now known as j-rod | |
| [18:12:17] | stoffel (stoffel!~quassel@p57B4CF37.dip.t-dialin.net) has quit (Remote host closed the connection) | |
| [18:13:03] | noahric_ (noahric_!4a7d3b41@gateway/web/freenode/ip.74.125.59.65) 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!~Goga777@shpd-95-53-220-29.vologda.ru) has quit (Read error: Operation timed out) | |
| [18:24:14] | slipcon (slipcon!~sjlipco@pool-96-255-3-66.washdc.fios.verizon.net) has joined #mythtv | |
| [18:25:50] | stuartm: | http://www.reghardware.com/2011/05/23/bbc_hd_1080p/ |
| [18:26:48] | NightMonkey (NightMonkey!debian-tor@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [18:34:08] | tris (tris!~tristan@173-164-188-122-SFBA.hfc.comcastbusiness.net) has quit (Excess Flood) | |
| [18:37:55] | tris (tris!~tristan@173-164-188-122-SFBA.hfc.comcastbusiness.net) 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!~wylie@ip24-251-22-58.ph.ph.cox.net) 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!~jordack@h69-131-44-221.mdsnwi.tisp.static.tds.net) 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: http://pastebin.com/5iFDcptq . It's an update of the last one you gave mar kk (the one at http://pastebin.ca/2067647 ). |
| [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!~andreaz@p57B93882.dip.t-dialin.net) has quit (Ping timeout: 252 seconds) | |
| [19:30:13] | andreax (andreax!~andreaz@p57B91EDE.dip.t-dialin.net) has joined #mythtv | |
| [19:32:14] | Beirdo: | http://pastebin.com/sNqmjHWC |
| [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: | http://pastebin.com/p29SxMha |
| [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!~jonatan@c83-252-237-63.bredband.comhem.se) 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@71.145.152.130) 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@71.145.152.130) 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!~quassel@184-97-180-91.mpls.qwest.net) has joined #mythtv | |
| [20:59:11] | fp__ (fp__!~fp@71.145.152.130) has joined #mythtv | |
| [20:59:41] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 240 seconds) | |
| [21:00:03] | JEDIDIAH__ (JEDIDIAH__!~jedi@cpe-76-185-75-39.tx.res.rr.com) 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@71.145.152.130) 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!~sjlipco@pool-96-255-3-66.washdc.fios.verizon.net) 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: | http://v4l2spec.bytesex.org/spec/r8087.htm |
| [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@71.145.152.130) 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@61.14.141.36) 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: | http://pastebin.com/ER59JsfP |
| [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) https://github.com/MythTV/mythtv/commit/ce7a5f62 |
| [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!~blaine@dsl-173-206-45-29.tor.primus.ca) has joined #mythtv | |
| [22:47:06] | kormoc is now known as kormoc_afk | |
| [22:58:53] | chris_k (chris_k!~blaine@dsl-173-206-45-29.tor.primus.ca) has left #mythtv () | |
| [23:01:35] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [23:45:51] | abqjp (abqjp!~abqjp@97.119.171.42) has quit (Quit: abqjp) | |
| Tuesday, May 24th, 2011 | ||
| [00:03:11] | cesman (cesman!~cecil@pool-71-254-162-41.lsanca.fios.verizon.net) has joined #mythtv | |
| [00:03:11] | cesman (cesman!~cecil@pdpc/supporter/professional/cesman) has joined #mythtv | |
| [00:03:11] | cesman (cesman!~cecil@pool-71-254-162-41.lsanca.fios.verizon.net) has quit (Changing host) | |
| [00:17:59] | fp__ (fp__!~fp@71.145.152.130) has quit (Ping timeout: 240 seconds) | |
| [00:38:49] | wagnerrp (wagnerrp!~wagnerrp_@mythtv/developer/wagnerrp) has quit (Ping timeout: 264 seconds) | |
| [00:40:01] | pheld (pheld!~heldal@cl-5.osl-01.no.sixxs.net) has quit (Quit: Leaving.) | |
| [00:44:31] | wagnerrp (wagnerrp!~wagnerrp_@2001:470:1f11:12f::a27) has joined #mythtv | |
| [00:44:31] | wagnerrp (wagnerrp!~wagnerrp_@2001:470:1f11:12f::a27) has quit (Changing host) | |
| [00:44:32] | wagnerrp (wagnerrp!~wagnerrp_@mythtv/developer/wagnerrp) has joined #mythtv | |
| [00:46:39] | gigem_ (gigem_!~david@mythtv/developer/gigem) has quit (Read error: Operation timed out) | |
| [00:48:23] | gigem_ (gigem_!~david@host103.16.intrusion.com) has joined #mythtv | |
| [00:48:24] | gigem_ (gigem_!~david@host103.16.intrusion.com) has quit (Changing host) | |
| [00:48:24] | gigem_ (gigem_!~david@mythtv/developer/gigem) has joined #mythtv | |
| [01:00:27] | mrand (mrand!~mrand@ubuntu/member/mrand) has quit (Ping timeout: 240 seconds) | |
| [01:10:04] | fp__ (fp__!~fp@71.145.152.130) has joined #mythtv | |
| [01:15:42] | mrand (mrand!~mrand@ubuntu/member/mrand) has joined #mythtv | |
| [01:17:35] | fp__ (fp__!~fp@71.145.152.130) has quit (Ping timeout: 260 seconds) | |
| [01:19:00] | markk: | danielk22: ok – backend patched – but it's not feeling the love:) It's trying the tune to a8auto8c:610000000, which should be t8qam64 |
| [01:29:20] | markk: | danielk22: so, if I comment out the dvb-c code and replace QString("a%1%2") with QString("t%1%2") in the dvb-t code it works. I'm guessing the latter is a typo but the former is being triggerred in error for some reason. |
| [01:29:45] | markk: | that's in HDHRChannel btw |
| [01:41:36] | taylorr: | sphery: when you are ready I've got another change for you – I had made a change and forgot – it might be required |
| [01:46:28] | sphery: | taylorr: yeah, just about to start testing... what change do I need? |
| [01:48:49] | taylorr: | sphery: change the buffer size first then change the kBufferSize = 16 * 1024 * 1024 in libs/libmythtv/RingBuffer.cpp (it's ringbuffer.cpp in master) |
| [01:49:15] | taylorr: | err, change the vdpau buffer size first |
| [01:52:33] | sphery: | I currently have the CalcReadAheadThresh() set with a #if 0 to make readblocksize = KB512; (the one someone on the list mentioned). I'll try removing that. I'm going to play some recordings with vdpau/vdpau to see some actual hiccups, first, though. |
| [02:06:14] | taylorr: | sphery: that isn't the only change necessary you also have to comment out where the readblocksize is incremented and decremented so that it's always what you set in CalcReadAheadThresh() |
| [02:06:18] | fp__ (fp__!~fp@71.145.152.130) has joined #mythtv | |
| [02:14:22] | jpabq: | taylorr, sphery, I took Mark Lord's suggestion and turn off vdpauhqscaling. I have only watched one show since, but during that show the only pause I noticed was when a new recording started up. |
| [02:15:43] | Batshua (Batshua!~Batshua@unaffiliated/batshua) has joined #mythtv | |
| [02:15:52] | Batshua (Batshua!~Batshua@unaffiliated/batshua) has left #mythtv () | |
| [02:18:06] | danielk22: | markk: The latter is definitely a typo. But I'm perplexed as to how the the dvb-c code is being triggered. If has_dvbc==true, has_dvbt==true and has_atsc=false we should just be setting the modulation to "auto", which would be the case with QAM64. |
| [02:27:19] | sphery: | taylorr: can I make those code changes on the frontend only? |
| [02:32:07] | markk: | danielk22: HDHRStreamHandler::Open tests for 'dvb' and sets both dvb-t and dvb-c tuner types. my hdhr returns "hdhomerun_dvbt" as its model. no idea what a dvb-c version returns but it should be safe to grep for dvbt and then use dvb for dvb-c |
| [02:32:34] | ** markk isn't sure that made complete sense ** | |
| [02:38:24] | taylorr: | sphery: yes, frontend only |
| [02:40:35] | sphery: | cool, now if I could only repro the pauses--can't seem to trigger it, tonight |
| [02:41:23] | taylorr: | sphery: yes, it's not very consistent – there are a lot of variables in play |
| [02:44:04] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya) | |
| [02:45:22] | danielk22: | markk: Nick told me they don't differentiate between the DVB-T and DVB-C devices so I assumed that both types of devices return the same string.. |
| [02:48:08] | markk: | danielk22: surely they don't advertise the dvb-c version as hdhomerun_dvbt :) |
| [02:52:59] | fp__ (fp__!~fp@71.145.152.130) has quit (Ping timeout: 240 seconds) | |
| [02:59:13] | danielk22: | markk: It is actually a DVB-T + DVB-C device; so I'm not sure... Also, it doesn't really solve the issue if we get it to work for DVB-T only devices but leave the combo devices in the lurch. |
| [03:00:03] | mrand (mrand!~mrand@ubuntu/member/mrand) has quit (Ping timeout: 252 seconds) | |
| [03:05:11] | iamlindoro: | Note that the .au device is DVB-T only, it's different hardware from the EU one |
| [03:05:42] | iamlindoro: | rereading what you just said it seems you're aware of that, so don't mind me ;) |
| [03:07:42] | markk: | danielk22: I don't know how to fix that – but I'm pretty sure the new get_tune_spec is going to break both dvb-t and dvb-c tuning for anything other than auto – as the spec string is modified for both dvb-t and dvb-c tuning |
| [03:09:11] | eharris (eharris!~eharris@99-179-7-82.lightspeed.austtx.sbcglobal.net) has quit (Read error: Operation timed out) | |
| [03:12:13] | danielk22: | markk: hmm, maybe I posted an old patch.. |
| [03:12:35] | eharris (eharris!~eharris@99-179-7-82.lightspeed.austtx.sbcglobal.net) has joined #mythtv | |
| [03:14:55] | markk: | danielk22: oh **** – sorry – I somehow managed to apply the first version you posted. let me try that again and get back to you. |
| [03:15:06] | danielk22: | http://pastebin.ca/2067647 <- this is the one you are using? it has "if (has_dvbc && !has_dvbt)" and "if (has_dvbt && !has_dvbc)" protecting the two blocks so the spec string should be modified for only one of the two types, or set to "auto" when it can't be disambiguated.. |
| [03:15:12] | danielk22: | ah.. ok :) |
| [03:15:39] | danielk22: | The later http://pastebin.ca/2067647 version does still have the typo.. |
| [03:17:56] | mrand (mrand!~mrand@ubuntu/member/mrand) has joined #mythtv | |
| [03:21:02] | sphery: | markk / danielk22 : FWIW, http://pastebin.com/5iFDcptq is an updated version of http://pastebin.ca/2067647 that has an incremented DB schema version (after the change I made earlier today)--but it will still have the typo that's in 2067647 |
| [03:25:36] | markk: | danielk22: ok... latest version of your patch (with typo fixed) now always uses auto – which is fine until I come to actually watching something and it doesn't get a lock. root problem is that for qam64 both has_dvbt and has_dvbc are still set |
| [03:31:07] | MythBuild (MythBuild!~MythBuild@184-106-209-209.static.cloud-ips.com) has quit (Quit: buildmaster reconfigured: bot disconnecting) | |
| [03:31:14] | MythBuild (MythBuild!~MythBuild@184-106-209-209.static.cloud-ips.com) has joined #mythtv | |
| [03:36:10] | MythBuild (MythBuild!~MythBuild@184-106-209-209.static.cloud-ips.com) has quit (Quit: buildmaster reconfigured: bot disconnecting) | |
| [03:36:16] | MythBuild (MythBuild!~MythBuild@184-106-209-209.static.cloud-ips.com) has joined #mythtv | |
| [03:36:49] | danielk22: | markk: hmm, ok — auto can be made to work, but I had hoped it was set to the right defaults depending on where the unit was sold.. |
| [03:36:53] | Beirdo: | MythBuild: force build master-freebsd-64bit now |
| [03:36:53] | MythBuild: | build #0 forced |
| [03:36:53] | MythBuild: | I'll give a shout when the build finishes |
| [03:41:13] | danielk22: | I guess we can use the symbolrate to disambiguate as well + try a fallback to DVB-C tuning if DVB-T tuning fails. |
| [03:42:27] | danielk22: | I'll write a new patch tmrw.. sorry about this one. |
| [03:43:11] | MythBuild: | Hey! build master-freebsd-64bit #0 is complete: Failure [failed configure core compile core] |
| [03:43:11] | MythBuild: | Build details are at http://code.mythtv.org/buildbot/builders/mast . . . bit/builds/0 |
| [03:44:36] | MythBuild (MythBuild!~MythBuild@184-106-209-209.static.cloud-ips.com) has quit (Quit: buildmaster reconfigured: bot disconnecting) | |
| [03:44:42] | MythBuild (MythBuild!~MythBuild@184-106-209-209.static.cloud-ips.com) has joined #mythtv | |
| [03:45:18] | Beirdo: | stupid typo |
| [03:45:36] | Beirdo: | MythBuild: force build master-freebsd-64bit now |
| [03:45:36] | MythBuild: | build #1 forced |
| [03:45:36] | MythBuild: | I'll give a shout when the build finishes |
| [03:46:12] | wagnerrp: | seems to actually be doing something this time |
| [03:48:05] | Beirdo: | yup, I missed an = in the extra-ldflags argument |
| [03:49:06] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [03:59:40] | dblain (dblain!~dblain@c-76-127-227-175.hsd1.ma.comcast.net) has joined #mythtv | |
| [03:59:40] | dblain (dblain!~dblain@mythtv/developer/dblain) has joined #mythtv | |
| [03:59:40] | dblain (dblain!~dblain@c-76-127-227-175.hsd1.ma.comcast.net) has quit (Changing host) | |
| [04:16:26] | Computer_Czar (Computer_Czar!~Unknown@69.4.155.83) has joined #mythtv | |
| [04:16:29] | MythBuild: | build #1 of master-freebsd-64bit is complete: Success [build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . bit/builds/1 |
| [04:16:52] | Beirdo: | woohoo |
| [04:17:20] | Beirdo: | MythBuild: force build 0.24-freebsd-64bit now |
| [04:17:20] | MythBuild: | build #0 forced |
| [04:17:20] | MythBuild: | I'll give a shout when the build finishes |
| [04:17:29] | Beirdo: | might as well test both :) |
| [04:18:07] | MythBuild: | build #2 of master-freebsd-64bit is complete: Exception [exception interrupted] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . bit/builds/2 blamelist: Mark Kendall <mkendall@mythtv.org > |
| [04:18:07] | MythBuild: | build #0 of 0.24-freebsd-64bit is complete: Exception [exception interrupted] Build details are at http://code.mythtv.org/buildbot/builders/0.24 . . . bit/builds/0 |
| [04:18:25] | Beirdo: | hehe |
| [04:18:41] | ** Beirdo watches wagnerrp stab the buildslave ** | |
| [04:32:26] | jya (jya!~jyavenard@gw2.hydrix.com) has joined #mythtv | |
| [04:32:26] | jya (jya!~jyavenard@gw2.hydrix.com) has quit (Changing host) | |
| [04:32:26] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [04:42:24] | jpabq: | taylorr, sphery, vdpauhqscaling didn't help. Thinking back, I bet the reason that first hour of viewing didn't have any pauses, is because the backend wasn't recording anything at that time. |
| [04:43:40] | taylorr: | jpabq: have you been following the discussions? there are multiple problems that are confusing people |
| [04:43:45] | sphery: | heh, I'm still trying to get a pause--haven't seen one all night |
| [04:46:00] | taylorr: | jpabq: we know what is causing the pauses when the backend is active – qapp->processEvents is calling MythSocket for the playbackbox from the UI thread |
| [04:46:36] | taylorr: | then there seems to be VDPAU specific pauses which are still under investigation |
| [04:47:11] | jpabq: | The qapp->processEvents is when a recording starts, or can that happen at any time? |
| [04:47:32] | taylorr: | jpabq: it can happen for many reasons |
| [04:48:04] | taylorr: | recording start/end, delete recording, commflag updates, etc |
| [04:49:23] | wylie (wylie!~wylie@ip24-251-22-58.ph.ph.cox.net) has quit (Quit: wylie) | |
| [04:49:41] | jpabq: | I notice in my mythcommflag logs that I can see a BUNCH of Received Event: 'UPDATE_FILE_SIZE ..." all together for the same show. Sometimes there will just be a single "Event:" message by itself, other times four or so seem to be processed at once (for the same recording). |
| [04:50:14] | wagnerrp: | there will be a bunch very rapidly at the start of a recording |
| [04:50:18] | taylorr: | jpabq: yep, and sometimes those cause enough delay in the UI thread to delay playback |
| [04:50:26] | wagnerrp: | but it will fade off to one every 10 seconds |
| [04:51:17] | taylorr: | I don't know how this should be fixed... hopefully someone that understands this code can help out |
| [04:51:49] | jpabq: | wagnerrp, does not fade for me. I see bunches of them together over the course of the recording. |
| [04:52:08] | taylorr: | we can not trigger MythSocket from the UI thread during playback – until that's averted then the pauses will continue |
| [04:52:23] | wylie (wylie!~wylie@ip24-251-22-58.ph.ph.cox.net) has joined #mythtv | |
| [04:52:35] | Beirdo: | so why did this become an issue lately? |
| [04:52:51] | Beirdo: | did we remove a playback thread that mitigated the issue or something? |
| [04:53:00] | jpabq: | I also see bunches of "Received Event: 'RECORDING_LIST_CHANGE UPDATE'" during the course of a recording. |
| [04:53:04] | Beirdo: | like in 0.24 (ish) |
| [04:53:06] | taylorr: | the playback thread was combined with the UI thread |
| [04:53:24] | Beirdo: | right |
| [04:53:47] | Beirdo: | sounds like that may have been not the best plan if this is the result :) |
| [04:54:07] | Beirdo: | ain't hindsight great? |
| [04:54:10] | taylorr: | Beirdo: it is required |
| [04:54:23] | taylorr: | we just need to handle things differently now |
| [04:54:47] | Beirdo: | how so? it worked for 23 versions of the code, and now it's required to do differently? I must be missing something |
| [04:55:10] | taylorr: | Beirdo: it was required for the MythUI-OSD functionality |
| [04:55:15] | Beirdo: | ahhh |
| [04:55:17] | Beirdo: | right |
| [04:55:39] | Beirdo: | well, at least we are all on the same page... now how do we fix it? :) |
| [04:56:22] | taylorr: | jpabq: you think it possible to add a qualifier to the qapp->processEvents – like if (!playing) qapp->processEvents |
| [04:56:49] | Beirdo: | doesn't processEvents also deal with keystrokes? |
| [04:56:49] | jarle (jarle!~jarle@70.84-234-133.customer.lyse.net) has quit (Remote host closed the connection) | |
| [04:56:51] | taylorr: | but I guess there are events that need handling during playback |
| [04:57:06] | taylorr: | yes, probably |
| [04:57:36] | jpabq: | Seeing those bunches, makes me wonder if may qapp->processEvents is not getting called often enough — so it ends up trying to process too many all at once? |
| [04:58:21] | Beirdo: | hmm. |
| [04:58:29] | taylorr: | jpabq: I think it is more related to a single event that for some reason takes the backend excessive amounts of time to respond |
| [04:58:49] | jpabq: | Of course, I am seeing that in the commflag log. I have not looked at the frontend log |
| [05:00:27] | jpabq: | If it is the "RECORDING_LIST_CHANGE" event, I could see that --- I am up to over 2500 recordings. |
| [05:02:14] | taylorr: | jpabq: the easiest way to tell is to add some verbosity, -v playback,network,extra, and then when you see a "drop" message in the logs look back before the drop and see if any of the MythSocket calls took excessive time |
| [05:03:34] | Beirdo: | danielk22: you mind if I commit the StartEncoding change that lets it carry on when EINVAL? |
| [05:05:56] | andreax (andreax!~andreaz@p57B91EDE.dip.t-dialin.net) has quit (Read error: Connection reset by peer) | |
| [05:12:38] | ybot (ybot!~quassel@61.14.141.36) has joined #mythtv | |
| [05:21:47] | wagnerrp: | MythBuild: force build master-freebsd-64bit now |
| [05:21:48] | MythBuild: | build forced [ETA 30m51s] |
| [05:21:48] | MythBuild: | I'll give a shout when the build finishes |
| [05:31:17] | Beirdo: | heh. /usr/src/linux-8.2-RELEASE/include |
| [05:31:19] | Beirdo: | classic |
| [05:31:44] | ** wagnerrp is from the futcah ** | |
| [05:35:04] | ripthejacker (ripthejacker!~quassel@210.89.42.78) has joined #mythtv | |
| [05:35:34] | ripthejacker (ripthejacker!~quassel@210.89.42.78) has left #mythtv () | |
| [05:51:00] | Beirdo: | danielk22: going to commit, but feel free to tweak it :) |
| [05:51:51] | Beirdo: | should keep other 2250 analog users from 0-byte files while we work out the best fix. I think I'll actually make patches to the driver, but I'm sure there are plenty others that will fail there too |
| [05:52:01] | skd5aner (skd5aner!~skd5aner@cpe-069-132-082-180.carolina.res.rr.com) has quit (Ping timeout: 264 seconds) | |
| [05:54:16] | wagnerrp: | it wants to schedule another build four minutes before the previous one ends? |
| [05:56:50] | Beirdo: | well, yeah, but it won't actually start until the other is done |
| [05:57:09] | Beirdo: | the ETA is an estimate, remember P) |
| [05:57:42] | Beirdo: | over time it gets fairly accurate, but to start, it ain't too close |
| [05:57:47] | wagnerrp: | well well see shortly if ccache has done its job |
| [05:58:30] | Beirdo: | yeah, it should help significantly |
| [06:01:29] | wagnerrp: | so if you get the same dozen warnings in a header included a dozen times, does it report 12 or 144? |
| [06:02:32] | Beirdo: | 144 :) |
| [06:02:37] | Beirdo: | most likely |
| [06:02:50] | Beirdo: | it just counts the warning lines AFAIK |
| [06:03:22] | MythBuild: | Hey! build master-freebsd-64bit #3 is complete: Failure [failed install plugins] |
| [06:03:22] | MythBuild: | Build details are at http://code.mythtv.org/buildbot/builders/mast . . . bit/builds/3 |
| [06:03:46] | pheld (pheld!~heldal@cl-5.osl-01.no.sixxs.net) has joined #mythtv | |
| [06:03:48] | wagnerrp: | huh... |
| [06:03:51] | Beirdo: | faililed? |
| [06:04:12] | wagnerrp: | should that one be using gmake too? |
| [06:04:23] | Beirdo: | did I miss one? |
| [06:04:25] | Beirdo: | crap |
| [06:04:28] | wagnerrp: | install |
| [06:04:37] | wagnerrp: | but it ran fine last time |
| [06:04:42] | wagnerrp: | which is the odd thing |
| [06:04:50] | wagnerrp: | something in mythweather tripped it up |
| [06:04:58] | wagnerrp: | mythweather was not run last time due to dependencies |
| [06:05:08] | Beirdo: | oooh |
| [06:05:27] | skd5aner (skd5aner!~skd5aner@cpe-069-132-082-180.carolina.res.rr.com) has joined #mythtv | |
| [06:05:40] | Beirdo: | let me go fix that |
| [06:06:06] | Goga777 (Goga777!~Goga777@shpd-95-53-176-227.vologda.ru) has joined #mythtv | |
| [06:08:13] | Beirdo: | we actually found a real issue :) |
| [06:08:24] | Beirdo: | just committed a fix |
| [06:13:02] | wagnerrp: | im getting primarily cache misses |
| [06:13:33] | Beirdo: | interesting |
| [06:13:42] | Beirdo: | it certainly speeds life up here |
| [06:14:55] | Beirdo: | where's the cache? |
| [06:15:08] | wagnerrp: | ~/.ccache |
| [06:15:40] | wagnerrp: | i just cranked up the max cache size |
| [06:15:44] | wagnerrp: | lets see if it uses it |
| [06:15:50] | wagnerrp: | it seemed to want to limit itself to 1GB |
| [06:15:53] | Beirdo: | ah |
| [06:15:58] | wagnerrp: | could you run ccache -s? |
| [06:16:03] | Beirdo: | coulda been rolling cache misses? |
| [06:16:12] | wagnerrp: | thats what im thinking |
| [06:17:47] | Beirdo: | http://pastebin.com/scs8bAbB |
| [06:18:10] | wagnerrp: | huh |
| [06:18:27] | Beirdo: | I wiped my cache (as gjhurlbu) a few days back |
| [06:18:37] | wagnerrp: | why so many files? |
| [06:18:40] | wagnerrp: | im around 4K |
| [06:19:05] | Beirdo: | the buildbot cache hasn't been cleaned in a while, and it has master, 0.24 and likely the mythsystem ones in there |
| [06:21:07] | Goga777 (Goga777!~Goga777@shpd-95-53-176-227.vologda.ru) has quit (Remote host closed the connection) | |
| [06:25:36] | martin_ (martin_!~quassel@static-88.131.29.2.addr.tdcsong.se) has joined #mythtv | |
| [06:25:37] | mrand (mrand!~mrand@ubuntu/member/mrand) has quit (Ping timeout: 264 seconds) | |
| [06:30:08] | MythBuild: | build #5 of master-freebsd-64bit is complete: Success [build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . bit/builds/5 |
| [06:31:09] | wagnerrp: | MythBuild: force build 0.24-freebsd-64bit now |
| [06:31:10] | MythBuild: | build #1 forced |
| [06:31:10] | MythBuild: | I'll give a shout when the build finishes |
| [06:39:20] | mrand (mrand!~mrand@ubuntu/member/mrand) has joined #mythtv | |
| [07:11:07] | MythBuild: | Hey! build 0.24-freebsd-64bit #1 is complete: Failure [failed show version] |
| [07:11:07] | MythBuild: | Build details are at http://code.mythtv.org/buildbot/builders/0.24 . . . bit/builds/1 |
| [07:13:01] | Beirdo: | oh give me a break |
| [07:14:34] | dagar (dagar!~dagar@agar.ca) has quit (Ping timeout: 260 seconds) | |
| [07:15:17] | dagar (dagar!~dagar@agar.ca) has joined #mythtv | |
| [07:16:32] | MythBuild (MythBuild!~MythBuild@184-106-209-209.static.cloud-ips.com) has quit (Quit: buildmaster reconfigured: bot disconnecting) | |
| [07:16:39] | MythBuild (MythBuild!~MythBuild@184-106-209-209.static.cloud-ips.com) has joined #mythtv | |
| [07:17:08] | Beirdo: | MythBuild: force build 0.24-freebsd-64bit now |
| [07:17:09] | MythBuild: | build #2 forced |
| [07:17:09] | MythBuild: | I'll give a shout when the build finishes |
| [07:21:15] | MythBuild: | build #2 of 0.24-freebsd-64bit is complete: Success [build successful] Build details are at http://code.mythtv.org/buildbot/builders/0.24 . . . bit/builds/2 |
| [07:22:59] | Beirdo: | there we co |
| [07:23:01] | Beirdo: | go... |
| [07:23:10] | Beirdo: | 4 min. ccache++ |
| [07:23:28] | Beirdo: | the failure was in the last step, cat version.h rather than the old version.cpp |
| [07:23:29] | Beirdo: | heh |
| [07:28:24] | len (len!~quassel@184-97-180-91.mpls.qwest.net) has quit (Remote host closed the connection) | |
| [07:32:50] | NightMonkey (NightMonkey!debian-tor@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!) | |
| [07:54:11] | martin_ (martin_!~quassel@static-88.131.29.2.addr.tdcsong.se) has quit (Ping timeout: 240 seconds) | |
| [08:09:01] | skd5aner (skd5aner!~skd5aner@cpe-069-132-082-180.carolina.res.rr.com) has quit (Read error: Connection reset by peer) | |
| [08:09:44] | skd5aner (skd5aner!~skd5aner@cpe-069-132-082-180.carolina.res.rr.com) has joined #mythtv | |
| [08:27:41] | simonckenyon (simonckenyon!~simoncken@195.7.61.12) has quit (Remote host closed the connection) | |
| [08:32:07] | simonckenyon (simonckenyon!~simoncken@195.7.61.12) has joined #mythtv | |
| [08:46:03] | DataTracer (DataTracer!byron@gateway/shell/devio.us/x-cligyzzxosqmgpol) has joined #mythtv | |
| [08:47:06] | DataTracer (DataTracer!byron@gateway/shell/devio.us/x-cligyzzxosqmgpol) has left #mythtv () | |
| [08:48:08] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya) | |
| [09:48:38] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [09:50:38] | martin_ (martin_!~quassel@static-88.131.29.2.addr.tdcsong.se) has joined #mythtv | |
| [10:05:03] | Guest84520 (Guest84520!~mike@c-24-21-63-118.hsd1.or.comcast.net) has quit (Remote host closed the connection) | |
| [10:05:50] | mike (mike!~mike@c-24-21-63-118.hsd1.or.comcast.net) has joined #mythtv | |
| [10:06:16] | mike is now known as Guest28359 | |
| [11:47:58] | gigem_ (gigem_!~david@mythtv/developer/gigem) has quit (Remote host closed the connection) | |
| [11:48:27] | gigem_ (gigem_!~david@mythtv/developer/gigem) has joined #mythtv | |
| [12:21:38] | Cougar (Cougar!~cougar@kkk.version6.net) has quit (Remote host closed the connection) | |
| [12:23:13] | Cougar (Cougar!~cougar@kkk.version6.net) has joined #mythtv | |
| [12:31:25] | highzeth (highzeth!~hz@hoiseth.no) has quit (Quit: Leaving) | |
| [12:33:20] | simonckenyon (simonckenyon!~simoncken@195.7.61.12) has quit (Remote host closed the connection) | |
| [13:15:04] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.