Back to Home / #mythtv / 2008 / 03 / Prev Day | Next Day
#mythtv IRC Logs for 2008-03-11

---Logopened Tue Mar 11 00:00:56 2008
00:24-!-briand [] has joined #mythtv
00:25-!-turbo [] has quit [Read error: 110 (Connection timed out)]
00:26-!-Jeff8 [] has joined #mythtv
00:27-!-Jeff8 [] has quit [Client Quit]
00:50-!-briand [] has quit [Read error: 110 (Connection timed out)]
00:50-!-briand [] has joined #mythtv
00:55-!-MrGandalv [] has joined #mythtv
00:56-!-MrGandalf [] has quit [Read error: 104 (Connection reset by peer)]
00:57<Chutt>dvbrecorder.cpp: In member function ‘virtual bool DVBRecorder::ProcessTSPacket(const TSPacket&)’:
00:57<Chutt>dvbrecorder.cpp:578: warning: control reaches end of non-void function
00:57<Chutt>that's _generally_ not a good warning :p
00:59<Chutt>also, there's some different definitions of ProcessTSPacket between the different recorders (some bool, some not)
00:59<Chutt>that's probably not correct, either..?
00:59-!-JoeBorn [] has quit ["homeward bound"]
00:59<Chutt>dvbci.h:#define MAXCASYSTEMIDS 16
00:59<Chutt>dvbci.cpp:#define MAXCASYSTEMIDS 64
01:09-!-MrGandalv [] has quit [Read error: 104 (Connection reset by peer)]
01:15<Chutt>allright - apparently current versions of trac are less leaky
01:15<Chutt>i'm going to attempt upgrading.
01:16<Chutt>it's also recommended to switch to python 2.5, but i'll need Snow-Man around in case of issues for that =)
01:17<kormoc>I migrated trac from python 2.4 to 2.5 and it went really really smoothly
01:17<kormoc>just fyi
01:18<Chutt>i need to update the box more than just python, though
01:18<kormoc>ahh, fair 'nuff
01:20-!-turbo [] has joined #mythtv
01:22-!-briand [] has quit [Read error: 110 (Connection timed out)]
01:25-!-abarbaccia [] has joined #mythtv
01:26-!-clever [] has quit [Connection timed out]
01:27<abarbaccia>hey - what is the build number for the stable 0.21 release
01:28<kormoc>you could look it up yourself
01:30<abarbaccia>kormoc - how do i do that?
01:30-!-clever [] has joined #mythtv
01:31<kormoc>go to trac, browse source, navigate to the branch you want info on, click on revision log
01:31<abarbaccia>got it - thanks!
01:39-!-abarbaccia [] has left #mythtv []
01:39-!-gabe76r [n=isit@] has joined #mythtv
01:39-!-gabe76r [n=isit@] has left #mythtv []
01:42-!-ahbritto [] has quit [Client Quit]
01:59-!-gnome42 [] has quit [Remote closed the connection]
02:22-!-kormoc [n=kormoc@unaffiliated/kormoc] has quit []
02:44-!-ahbritto [] has joined #mythtv
02:59-!-loops [] has joined #mythtv
03:19<stuarta>has anyone reported audio buffering problems in 0.21-fixes?
03:19<stuarta>rebuilt the mac frontend last night and it had lots of audio buffering issues
03:19<stuarta>only cured by playback of the recording at timestretch != 1x
03:20*stuarta apologizes for not having caught up on the mailing list yet
03:25<xris>only mac issues I've had are just slow playback.. and I just figured it was slow X, and using a laptop.
03:26-!-NightMonkey [n=NightMon@pdpc/supporter/sustaining/NightMonkey] has quit [Read error: 113 (No route to host)]
03:26<stuarta>dunno if it's mac specific yet
03:33-!-MaverickTech [] has joined #mythtv
03:34<xris>I did have some audio sync issues when watching something tonight from linux, though
03:36<xris>anyway, time for me to sleep. :)
03:36-!-xris [] has quit []
04:01<janneg>stuarta: alsa had buffering problems on linux but those were fixed before the release
04:03-!-MGisbers [] has quit [Read error: 110 (Connection timed out)]
04:17-!-MGisbers [n=mgisbers@] has joined #mythtv
04:21-!-briand [] has joined #mythtv
04:23-!-turbo [] has quit [Read error: 110 (Connection timed out)]
04:28-!-otwin [n=otwin@] has quit [Read error: 104 (Connection reset by peer)]
04:28-!-otwin [n=otwin@] has joined #mythtv
05:14-!-purserj [] has quit [Nick collision from services.]
05:15-!-purserj [] has joined #mythtv
05:36-!-turbo [] has joined #mythtv
05:38-!-briand [] has quit [Read error: 110 (Connection timed out)]
05:39-!-despen [] has joined #mythtv
05:40-!-despen [] has left #mythtv []
05:42-!-TheTUX2 [] has joined #mythtv
05:43-!-TheTUX2 [] has left #mythtv []
05:47-!-axod [i=568bbc54@gateway/web/ajax/] has joined #mythtv
05:47-!-axod [i=568bbc54@gateway/web/ajax/] has left #mythtv []
05:58-!-dagar_ [] has joined #mythtv
06:00-!-dagar [] has quit [Connection timed out]
06:02-!-M0nk3Eee [n=matt@] has joined #mythtv
06:03<M0nk3Eee>hi all can anyone tell me what the process is for myth getting into the ubuntu repositories? when do you think the latest version will hit ubuntu repo? months, years?
06:04<hads>M0nk3Eee: That's more of an Ubuntu channel question.
06:04<hads>Try #ubuntu-mythtv
06:05<stuarta>janneg: okay that's interesting.
06:06<stuarta>is that new audio upmixing code disabled when timestretch != 1x
06:08<M0nk3Eee>thanks hads
06:08-!-M0nk3Eee [n=matt@] has left #mythtv []
06:24-!-briand [] has joined #mythtv
06:26-!-turbo [] has quit [Read error: 110 (Connection timed out)]
06:28-!-MrGandalv [] has joined #mythtv
06:29-!-iamlindoro__ [] has joined #mythtv
06:30-!-iamlindoro_ [] has quit [Read error: 104 (Connection reset by peer)]
06:50-!-turbo [] has joined #mythtv
06:51-!-briand [] has quit [Read error: 110 (Connection timed out)]
06:52-!-dagar_ [] has quit [Read error: 110 (Connection timed out)]
07:01-!-MrGandalv [] has quit ["work"]
07:02-!-dagar_ [] has joined #mythtv
07:05-!-joobie [] has joined #mythtv
07:19-!-turbo [] has quit [Connection timed out]
07:19-!-turbo [] has joined #mythtv
08:00-!-joobie [] has quit ["This computer has gone to sleep"]
08:05<laga>gbee: did you really mean to reference #4689 when comitting r16505
08:05<gbee>no, 4869, but it's not worth correcting
08:09-!-purserj [] has quit [Read error: 104 (Connection reset by peer)]
08:09-!-purserj [] has joined #mythtv
08:10-!-Cardoe [n=Cardoe@gentoo/developer/Cardoe] has quit ["Leaving"]
08:13-!-BleedAway [] has joined #mythtv
08:16-!-joobie [] has joined #mythtv
08:34-!-joobie [] has quit [Read error: 110 (Connection timed out)]
08:44-!-lsobral [n=sobral@] has joined #mythtv
09:16-!-Cardoe [n=Cardoe@gentoo/developer/Cardoe] has joined #mythtv
09:22-!-kwizart [n=kwizart@fedora/kwizart] has joined #mythtv
09:30-!-MrGandalf [] has joined #mythtv
09:42-!-skamithi [] has joined #mythtv
09:50-!-purserj [] has quit [Read error: 104 (Connection reset by peer)]
09:50-!-purserj [] has joined #mythtv
10:56-!-bendailey [] has joined #mythtv
10:59-!-ToadP_ [] has joined #mythtv
11:14-!-ToadP [] has quit [Read error: 110 (Connection timed out)]
11:22-!-waini [] has joined #mythtv
11:23-!-waini [] has left #mythtv ["Apple forever!"]
11:30-!-skamithi [] has quit ["WeeChat 0.2.3"]
11:32-!-clever [] has quit [Read error: 110 (Connection timed out)]
11:38<Cardoe>so is blootube-wide and friends kept up to date anymore?
11:40<gbee>I think they are up to date for 0.21, but I wouldn't count on them being around for 0.22
11:41<laga>have you guys seen reports about upnp related memory leaks in 0.21?
11:41<laga>the mythbuntu packages have seen two so far
11:42<gbee>laga: no?
11:42<gbee>backend I assume?
11:42*stuarta builds > 16461 to test if the audio buffering problem is gone.
11:42<laga>gbee: yes, the backend
11:42<gbee>I don't have any upnp devices, but the valgrinding I did 2/3 weeks ago was clean
11:43<gbee>well aside from the leaks I fixed at the time
11:43<laga>gbee: it seems to be caused if they are upnp devices (eg windows boxes) on the network. someone reported mythbackend taking 1.5G memory after a few hours. what debug information would be helpful?
11:44<gbee>only really useful information would be a report from valgrind
11:44<gbee>if it was leaking threads gdb might help, but I doubt that is the case here
11:45<laga>gbee: is that documented somewhere?
11:45<gbee>I'll ask GreyFoxx or CDev if they can take a look, I don't even have a Windows box
11:45<Chutt>no such leak here
11:45-!-leprechau [] has joined #mythtv
11:45-!-leprechau [] has quit [Client Quit]
11:46<Chutt>and i've got 2 or 3 other upnp devices on the network
11:46<gbee>laga: no, but it's pretty simple "valgrind --leak-check=full mythbackend"
11:46<laga>gbee: and then it runs for a while?
11:46-!-ahbritto [] has quit [Client Quit]
11:47<stuarta>hmmm, already have 16490
11:47<gbee>laga: yeah, if the leak is as big as suggested then it won't take too long, but the backend should run fine under valgrind for an extended period if the machine has the resources
11:48<laga>gbee: does it generate a log file?
11:48<gbee>upon exiting from the backend (ctrl-c) it will present a report, which should be copy/pasted into ticket
11:49<laga>gbee: great, thanks.
11:49<gbee>or add --log-file-exactly=valgrind.log
11:49<stuarta>laga: valgrind --leak-check=full --error-limit=no --log-file=logfile -v -- mythbackend <usual options> | tee backend.log
11:49<gbee>which might be easier than copying the output buffer
11:49<stuarta>i often also add --show-reachable=yes
11:50<stuarta>cause often the memory isn't lost, just continually consumed
11:53<laga>doyouneed debugging symbols for that?
11:54<stuarta>helps, but not essential
11:54-!-loops [] has quit ["Leaving"]
11:54<stuarta>depends if you like looking for needles in haystacks or teacups
12:02-!-loops [] has joined #mythtv
12:07-!-gnome42 [] has joined #mythtv
12:12-!-jk1joel [] has quit [":q!"]
12:14-!-jk1joel [] has joined #mythtv
12:17-!-loops [] has quit ["Leaving"]
12:18-!-JoeBorn [] has joined #mythtv
12:20-!-loops [] has joined #mythtv
12:26-!-xris [] has joined #mythtv
12:29-!-Viaken [] has joined #mythtv
12:30<Viaken>I just noticed the memory reduction for the frontend listed in the release notes. Thank you!! :) I was hoping the new version would be easier on memory.
12:32-!-Viaken [] has left #mythtv ["Ptwang!"]
12:41-!-beavis [] has joined #mythtv
12:46<gnome42>Heya gbee, here is an updated version of Get-Me-A-Really-FreeCard! patch
12:47<gnome42>just some tweaks and cleaned up a bit
12:47<gnome42>it works well in the testing I can do here
12:54<danielk22>Why not just allow browse to show all available channels? Maybe with an asterisk on the ones on other tuners?
12:57-!-MrGandalf [] has quit [Remote closed the connection]
13:00<gnome42>danielk22: yeah, that sounds good as well. But it's a different issue no?
13:01<danielk22>how so?
13:01<gnome42>I was planning on tackling the browse mode next, if there was agreement on it.
13:01-!-MrGandalf [] has joined #mythtv
13:01<danielk22>I think as long as it's optional it's ok.. not everyone wants the extra network burden involved in supporting it..
13:02<gnome42>Fixing browse mode to show all available channels still doesn't fix the problem of spawning a livetv session on a card that could be restricted to one mux.
13:03<danielk22>There is nothing wrong with starting livetv on a restricted card, so long as the user can just as easily change channels as they would normally.
13:04<danielk22>any DVB card can become mux restricted while someone is watching livetv anyway.
13:05<gnome42>ah, ok. I see your point now :)
13:09-!-dekar1 [] has joined #mythtv
13:12-!-aevil [] has joined #mythtv
13:16-!-MrGandalf [] has quit [Remote closed the connection]
13:17-!-MrGandalf_ [] has joined #mythtv
13:23<GreyFoxx>Frost: The menu option lets you define up to 5
13:24-!-MrGandalf_ is now known as MrGandalf
13:26-!-dekarl [] has quit [Read error: 110 (Connection timed out)]
13:33-!-Nikas [] has joined #mythtv
13:33<gbee>Viaken probably didn't notice that I backported that to 0.20.2 .....
13:41<gnome42>danielk22: I'm running and it seems to work
13:42<gnome42>it is very heavy though. Cruising browse mode channels takes my backend up to 50% cpu util.
13:43<danielk22>gnome42: I'm hoping for a more efficient solution..
13:43<gnome42>yeah :)
13:43<danielk22>something akin to the EPG browsing maybe
13:45<gnome42>something like the caching in the EPG browsing would be adequate maybe?
13:46<danielk22>with maybe a reload once in a while + check before an actual channel change..
13:48<janneg>gnome42: a more efficient solution for GetFreeRecorderList would be check if all online recorders of a input group are free
13:49<janneg>for dvb we could short circuit it with a reusing parentcardid
13:49<janneg>s/a //
13:54<gbee>Chutt: the 'left key to exit screen' behaviour that is used in some places, is that something we want to keep and if so, should it apply everywhere?
13:57<gnome42>Hi janneg, hmm, ok thinking .... did you mean GetFreeRecorder()?
13:58<janneg>gnome42: they have both same the problem
14:00-!-NightMonkey [n=NightMon@pdpc/supporter/sustaining/NightMonkey] has joined #mythtv
14:00<janneg>gbee: it doesn't make sense for some menu layouts (the biggest disadvantage of metallurgy) but otherwise it's very useful
14:01<gbee>janneg: it's not the menus that I'm thinking about, but screens like Watch Recordings and plugins like mythflix
14:01<gbee>seems to me that behaviour should be consistent, either left exits all screens or none of them
14:02<gbee>left moving to the previous menu _is_ useful and I'd keep it that way
14:03<janneg>the only exeption I know are the toggle buttons (auto expire in the watch recordings menu)
14:05-!-MGisbers [n=mgisbers@] has quit [Read error: 110 (Connection timed out)]
14:05<gbee>if it applies to all screens then I'd put the code into mythui instead of repeating the code everywhere (if NextPrevWidgetFocus(false) is called when we are at the start of the focus list, then pop the screen)
14:19-!-phatmonke [n=ben@] has joined #mythtv
14:19<sphery>gbee: See inline help for UseArrowAccels
14:19<sphery>gbee: Though I'll say that it's annoying when on a page that requires, i.e., left/right to switch columns (like the Watch Recordings screen)
14:20<sphery>BTW, mythtv/programs/mythfrontend/globalsettings.cpp +2219
14:20<gbee>yeah, got i
14:20<sphery>IMHO, it should /only/ be used if that's enabled. I think some of the code ignores that, though.
14:22-!-skamithi [] has joined #mythtv
14:22<gbee>that's what I'll do then, it will go into mythscreentype so that it effects all mythui based screens but only if UseArrowAccels is enabled
14:23<sphery>sounds good.
14:23-!-MGisbers [] has joined #mythtv
14:24<gbee>mythflix does it without checking that setting first, which is what confused me
14:26<sphery>Yeah. Many have the setting enabled but don't know it (enabled is the default), so they assumed that's just the way it works, and hard-coded the functionality into their UI code.
14:26<gbee>I'd like to eradicate as much duplication in the code as I can, so having navigation key press events such as Escape, Left/right/Up/Down and Select handled in mythui whilst still allowing screens to override it if they want
14:27<sphery>stuarta: Though the ALSA buffering issues were fixed in the 0.21 release, Mark released it was not fixed properly. See
14:28<sphery>guess it's technically comment:16, but close enough
14:30<sphery>gbee: And, less duplication of code means more consistent application of functionality (i.e. so that we don't forget to check UseArrowAccels :)
14:32<sphery>BTW, did you see I promoted your watched flag to a major feature (at least on the list):
14:33-!-aevil [] has quit [Remote closed the connection]
14:42-!-loops [] has quit ["Leaving"]
14:55<zavex>is there an easy way to get the location of the next keyframe from NuppelVideoPlayer?
14:56<zavex>i was hopping to change mythcommflag so it places the marks at key frames
14:58<xris>why would you want to do that? key frames can often be a second or two apart
14:58<janneg>sphery: it is one of the bigger features. I totally forgot that it was new in 0.21. we need more releases
14:59<zavex>i usually end up moving the cut marks to key frames before i transcode to remove commercials from mpeg2 recordings
14:59<sphery>janneg: I agree (on all counts). It's especially nice for users as it now provides a way to allow autoexpire to determine whether or not to allow re-record.
15:00<zavex>xris:i had read that it helps with audio sink
15:00<janneg>zavex: the transcoder should handle non keyframe cuts fine
15:01-!-loops [] has joined #mythtv
15:02<sphery>zavex: There are 2 different ways that marks are applied--some use MARK_GOP_START and some use MARK_GOP_BYFRAME
15:02<sphery>zavex: see #799
15:04<zavex>sphery:isn't that the ticket that has to do with the time shown doubling for some recordings?
15:04<sphery>zavex: IIRC, ivtv uses MARK_GOP_BYFRAME with keyframe distance set to 1, others use MARK_GOP_START
15:05-!-tris [] has quit [Remote closed the connection]
15:05<sphery>zavex: yep. It's related (the description on #799 isn't nearly a good summary of the issue--which is why it's still an outstanding ticket).
15:05-!-tris [] has joined #mythtv
15:06-!-tris- [] has joined #mythtv
15:06<sphery>zavex: Also, see (which, IIRC, is a prereq to fixing #799)
15:07-!-tris- [] has quit [Client Quit]
15:07<sphery>zavex: In other words, to fix everything properly, we /need/ mythcommflag to place marks at every frame, not at just keyframes
15:07-!-rn114 [] has joined #mythtv
15:07<zavex>ok thanks for all the info
15:08<zavex>now i just need to digest it all
15:09<sphery>zavex: Also, as far as editing goes, there's a key you can press to skip to the next keyframe...
15:09<zavex>sphery: yep that is what i have been doing so far
15:09<zavex>sphery: though seems maybe i need to see if i really even need to bother doing that
15:11<sphery>zavex: either way, it should handle the cut appropriately. ghausher did a lot of code for the "lossless" MPEG-2 to MPEG-2 to account for cuts at non-keyframes (reencoding around the cut as required). When transcoding, it doesn't matter.
15:11-!-aevil [] has joined #mythtv
15:14<zavex>ok, thanks again everyone for the info
15:18-!-j-rod [n=nnnjarod@] has left #mythtv ["I give up!"]
15:20-!-rn114 [] has quit [Read error: 113 (No route to host)]
15:20-!-rn114__ [] has joined #mythtv
15:26<gbee>sphery: keyframe distance for ivtv is set to one per second, or 25 frames for PAL and 30 for NTSC
15:26-!-kormoc [n=kormoc@unaffiliated/kormoc] has joined #mythtv
15:27<gbee>hmm, now that I've said it, that sounds wrong
15:27<gbee>15 and 20? ... ahh just ignore me, it's not really important
15:39<janneg>iirc 15 for pal and 18 for ntsc
15:40-!-loops [] has quit [Remote closed the connection]
15:44<kormoc>What are people's thoughts on the whole 'tag' push (Taging media and doing dynamic categorizing vs static directory categorizing)
15:44<stuarta>sphery: cheers i'll have a look
15:45<sphery>gbee: Yeah. You're right. It's the patch on #1088 that changes the internal variable for the keyframe distance to 1 (which is a hack that's the reason those patches haven't been used)...
15:45<sphery>gbee: Was just glancing over the conversation, you, me, and CDEV had last Aug 12, and didn't read enough context around your comment to figure out what set the keyframe distance to 1... :)
15:46<sphery>stuarta: danielk22 is actively soliciting testers for that patch, so he'd appreciate some feedback (especially if it corrects a problem in post-0.21 code)
15:46<stuarta>just downloading it to test :)
15:46-!-loops [] has joined #mythtv
15:47<gbee>kormoc: I like the idea of categorizing on more than one thing e.g. film,comedy,horror or by cast/crew
15:51<gbee>I'm not really into this 'Web 2.0' idea of tagging all sorts of weird and irrelevant information, if that's what you mean
15:55<gbee>The option to filter down so that I end up with a list of "Thrillers or Comedies with Robert DeNiro made before 1990" would be good
15:56<gbee>but then I don't actually have that many films/dvds stored under mythvideo
15:56<kormoc>gbee, Well, there's people who want to switch myth video to tag based, and if myth video goes, myth gallery should likely go as well, and then if myth gallery goes, the gallery we pick for mythweb should be tag based as well
15:57<gbee>tagging makes more sense for mythgallery IMHO, but I'm not opposed to it being used everywhere else
15:58<stuarta>hmmm, latest -fixes that i built today doesn't exhibit the same problem in the logs
15:58<stuarta>but the appearance is similar.
15:58<stuarta>(jerky video playback)
15:59<stuarta>yesterday it was buffer overflows, today it's the A/V sync code getting not quite in sync
15:59*stuarta applies the patch to test
16:01<janneg>how do we want to proceed with the qt4 port? I want to merge mythtv-qt4 as soon as it runs
16:02<janneg>starting the real port (eleminating qt3 support code) is imho too much effort in a branch
16:02<janneg>any change in trunk will cause conflics
16:07-!-erik_ [] has joined #mythtv
16:14<gbee>janneg: I'm all for doing the qt4 branch merge as soon as possible
16:14<gbee>as long as it doesn't conflict with any of my patches ;)
16:15<janneg>it will :(. I'm fixing the last merge atm and it is a conflict in every touched file or so
16:15*stuarta suggests asking the boss
16:16<kormoc>gbee, Yeah, I sorta want to put in a tag based gallery into mythweb if tags are going to be used, cause I don't want to deal with two different galleries
16:17-!-moodboom [] has quit [Client Quit]
16:18<gbee>janneg: mainly it's the mythui stuff I'm working on, maybe I should stop work until the merge?
16:21<janneg>nah, I don't think it will be ready fast enough to stop working
16:21<Chutt>i'd prefer a merge sooner
16:21-!-MGisbers [] has quit [Remote closed the connection]
16:22<janneg>the plugins are completely untouched for example
16:25-!-joobie [] has joined #mythtv
16:29<janneg>Chutt: ok, I'll fix mythtv-qt4 today. There is at least one problem which needs to be solved before the merge: db inserts in mythtv-setup are broken
16:30-!-loops [] has quit ["Leaving"]
16:30<janneg>and it would be nice to eliminate the flicker, probably double buffering just needs to be enabled
16:31-!-MrGandalf [] has quit ["home"]
16:35-!-dagar_ is now known as dagar
16:38<Chutt>janneg, post to developers first
16:41<janneg>sure, I don't wanted merge as soon as I found the bug, I'm aiming at early next
16:41<Chutt>sounds good
16:42<Chutt>i assumed =)
16:42<sphery>gbee: Any problems with including DB schema version in the --version output? (Now that we actually check it before allowing apps to run...)
16:42-!-skamithi [] has quit ["WeeChat 0.2.3"]
16:44<janneg>I figured but I think in this case it helps to be explicit
16:44<gbee>sphery: no problem
16:45<gbee>but if users start reporting that they are using version 2115 then I'll have to remove it ;)
16:46<sphery>lol. OK. I'll make a patch (that attempts to make it clear :).
16:48-!-loops [] has joined #mythtv
16:51-!-borga2 [] has joined #mythtv
16:52-!-borga2 [] has left #mythtv []
16:52<janneg>and I'll post to dev
16:56-!-loops [] has quit ["Leaving"]
17:04-!-renatofilho^_ [n=renato@] has quit ["Ex-Chat"]
17:06<gbee>what exactly does the postprocess filter, or any of the playback filters, do?
17:08<janneg>depends on the filter. they are changing the decoded video stream (we have afaik no audio filters)
17:09-!-j-rod [n=nnnjarod@] has joined #mythtv
17:12<gbee>just wondering what the benefits are, I can't think of any questions asked on the lists or in IRC where the answer has been 'use the playback filters'
17:13<gbee>maybe this is a more appropriate in the -users channel
17:13-!-erik_ [] has quit ["Lämnar"]
17:18-!-toresbe [] has joined #mythtv
17:19-!-dagar [] has quit [Read error: 104 (Connection reset by peer)]
17:19-!-dagar_ [] has joined #mythtv
17:20-!-loops [] has joined #mythtv
17:26-!-mattwire [] has joined #mythtv
17:27-!-foxhunt [] has joined #mythtv
17:27-!-rn114__ is now known as robthebob
17:33<Chutt>trac/anon svn will be down for a little bit
17:40-!-turbo [] has quit [Read error: 110 (Connection timed out)]
17:45-!-loops [] has quit ["Leaving"]
17:45-!-MrGandalf [] has joined #mythtv
17:46-!-jhulst [n=jhulst@unaffiliated/jhulst] has joined #mythtv
17:49-!-loops [] has joined #mythtv
17:49-!-ahbritto [] has joined #mythtv
17:53-!-aevil [] has quit [Remote closed the connection]
17:59-!-loops [] has quit ["Leaving"]
18:00<stuarta>sphery: fyi, that patch didn't help much
18:00<sphery>stuarta: :(
18:01<stuarta>i'll report as such to trac (if it's up)
18:01<stuarta>i do need to check if it touches the coreaudio output however
18:01-!-Cardoe [n=Cardoe@gentoo/developer/Cardoe] has quit ["Leaving"]
18:03<sphery>stuarta: Your issue may be unrelated, but I thought that might be a good thing to try. Unfortunately, I know nothing of Mac, so I can't help you with it.
18:03<stuarta>i'm still a complete amateur on the mac.
18:03<stuarta>so many frameworks
18:04-!-toresbe_ [] has joined #mythtv
18:04<stuarta>it makes an interesting diversion from real coding :)
18:07<stuarta>one day i might even sit down and work out the video interfaces on osx
18:07<sphery>Captain_Murdoch: We have a problem with the storagegroups DB upgrade (1171). See and . Second report of the same DB corruption (multiple RecordFilePrefix values for a given host--no clue how that happens, but...).
18:08<sphery>Captain_Murdoch: I was thinking of just modifying the SQL for 1171 to "prune" out any dups (though I still have to figure out how to do that). Think that's OK? Anyone who's at or beyond 1171 won't need the fix, so...
18:11-!-loops [] has joined #mythtv
18:13-!-phatmonke [n=ben@] has quit []
18:16<sphery>Captain_Murdoch: Looks like we can modify the query to: INSERT storagegroup (groupname, hostname, dirname) SELECT 'Default', hostname, data FROM settings WHERE value = 'RecordFilePrefix' GROUP BY hostname, data;
18:16-!-mattwire [] has quit [Read error: 110 (Connection timed out)]
18:18-!-toresbe [] has quit [No route to host]
18:19-!-Th3On3 [n=N3o@] has joined #mythtv
18:19-!-toresbe_ is now known as toresbe
18:19<Th3On3>i have a problem
18:19<Th3On3>i am using mplayer to see xvid movies on mythtv
18:19*stuarta speculatively points at the topic
18:20<Th3On3>but when i hit 'esc' key it exits mplayer and mythtv ?!?!?!?
18:20<Th3On3>i am using mythubuntu
18:25<gbee>Th3On3: try #mythtv-users and also try using the internal player instead (I'm in -users)
18:30<sphery>d'oh. Caught by the no anon Trac...
18:37-!-mattwire [] has joined #mythtv
18:37-!-JoeBorn [] has quit ["off to see the wizard!"]
18:47-!-henkie [] has joined #mythtv
18:49-!-_tux68_ [] has joined #mythtv
18:51-!-beavis [] has quit ["Verlassend"]
18:52-!-_tux68_ [] has quit [Client Quit]
18:55-!-bendailey [] has left #mythtv []
18:57<stuarta>is trac sending out ticket changes atm?
18:59<gbee>(21:33:29) Chutt: trac/anon svn will be down for a little bit
18:59<stuarta>yeah, read that, missing some stuff from 12 hrs ago
18:59<gbee>damn, second zero byte recording in as many days
19:00<gbee>ahh, dunno
19:00<stuarta>#4764 all changes after danielk changing critical -> minor
19:01-!-mattwire [] has quit [Read error: 110 (Connection timed out)]
19:02<gbee>I've got a bunch of changes after that
19:02-!-mattwire [] has joined #mythtv
19:05-!-henkie [] has quit [Read error: 104 (Connection reset by peer)]
19:09-!-mattwire_ [] has joined #mythtv
19:14-!-turbo [] has joined #mythtv
19:14-!-turbo is now known as briand
19:17*stuarta finds the missing emails
19:17<gbee>weird, my backends become unstable - insists it's recording programmes that then don't appear in Watch Recordings, refuses to do anything when I ask it to Stop the Recording, tells me that the file for the recording isn't yet available when it's been recording for 20 minutes etc
19:18-!-PointyPumper [n=pintlezz@] has quit [Connection timed out]
19:20-!-mattwire [] has quit [Read error: 113 (No route to host)]
19:25-!-Mikeee [] has joined #mythtv
19:25-!-_gunni_ [] has joined #mythtv
19:26-!-Mikeee [] has left #mythtv []
19:28-!-robthebob [] has quit [Read error: 113 (No route to host)]
19:32-!-MavT [] has joined #mythtv
19:36-!-purserj [] has quit [Remote closed the connection]
19:47-!-MaverickTech [] has quit [Read error: 110 (Connection timed out)]
19:48-!-jhulst [n=jhulst@unaffiliated/jhulst] has quit [Connection timed out]
19:48<gbee>well problem solved, had to do a full re-scan, seems frequencies may have changed but I can find no mention of it anywhere in scheduled maintenance etc
19:54<danielk22>gbee: part of what I want to do in the channel scanner branch is make it safe to do a daily rescan of channels, and then pop up something on the frontends asking you to approve changes that the channel scanner suggests..
19:55<gbee> danielk22: that would be great
19:56<gbee>the old system were updates were made as changes were detected was good too, except that it deleted channels first losing settings, xmltvids etc
19:56<danielk22>yeah, the scanner used to do this, but it would delete channels that were temporarily off air..
19:57<danielk22>this was obviously a very bad thing...
19:57<gbee>there is still an issue with the current scanner, even with minimal updates where it doesn't preserve eit and visibility settings
19:57<gbee>I did have a patch for that somewhere
19:57<danielk22>that sounds like a bug..
19:59<gbee>I'd forgotten about it, otherwise I would have dug up the patch and opened a ticket for 0.21
20:03-!-Nikas [] has quit []
20:14<MrGandalf>danielk22: if you manage to get the scanner working to that level, I can finally dump my old perl script. That would be excellent.
20:16<danielk22>it will take a while before I get there, it's a near total rewrite.
20:16<MrGandalf>though my script does pretty well.
20:20-!-danielk22 [] has left #mythtv []
20:20-!-_gunni_ [] has quit ["KVIrc 3.2.4 Anomalies"]
20:25-!-danielk22 [] has joined #mythtv
20:30<gbee>danielk22: can't find the patch but a check check shows that UpdateSDTinDB and UpdatePMTinDB are passing values of false to ChanUtil::UpdateChannel() for use_on_air_guide and hidden
20:31<gbee>appears only UpdateVCTinDB is doing the right thing, or so it seems from a casual look
20:33<gbee>err, make that UpdateSDTinDB will pass true for use_on_air_guide if eit is available, irrespective of what the previous value in the database was
20:34-!-reynaldo [] has joined #mythtv
20:37-!-mattwire_ [] has quit ["Leaving"]
20:38<danielk22>gbee I think the intended behaviour was to enable EIT when found on the ATSC side, since at the time EIT was just coming online in the ATSC world.. the logic was probably copy-n-pasted to the SDT updated code.
20:43<gbee>not sure where the logic to maintain the existing values is best put, in ChanUtil::UpdateChannel() or in SIScan::UpdateSDTinDB and SIScan::UpdatePMTinDB? I can sort out the patch and though it should be straightforward I can more easily do the necessary testing
20:44<danielk22>UpdateSDTinDB and UpdatePMTinDB probably..
20:48<gbee>There is no method in ChanUtil which will obtain the values of useonairguide and visible from the database, to then make it accessible in SIScan, I don't want to put a db query into SIScan directly so I'll add something similar to GetChannelData() e.g. GetChannelSettings() for that
20:50<gbee>something to do tomorrow if the weather doesn't improve
20:51-!-kwizart [n=kwizart@fedora/kwizart] has quit [Read error: 113 (No route to host)]
20:55-!-Th3On3 [n=N3o@] has quit ["leaving"]
21:01-!-PointyPumper [i=Pintlezz@] has joined #mythtv
21:07-!-DaedalusX [] has joined #mythtv
21:10-!-davilla [] has joined #mythtv
21:20-!-Viaken [] has joined #mythtv
21:20-!-Viaken [] has left #mythtv ["ptwang!"]
21:30-!-ToadP_ [] has quit [Client Quit]
21:30-!-ToadP [] has joined #mythtv
21:32-!-th_ [] has joined #mythtv
21:32-!-th_ [] has quit [Read error: 54 (Connection reset by peer)]
21:51-!-th1 [] has quit [Read error: 113 (No route to host)]
21:53<Anduin>Any chance of a dot release milestone?
21:59-!-turbo [] has joined #mythtv
22:01<xris>september? ;)
22:01-!-briand [] has quit [Read error: 110 (Connection timed out)]
22:01-!-turbo is now known as briand
22:17-!-Looter [] has joined #mythtv
22:19-!-ahbritto [] has quit [Client Quit]
22:32-!-knowledgejunkie [n=knowledg@unaffiliated/knowledgejunkie] has joined #mythtv
22:49-!-joobie_ [] has joined #mythtv
22:50-!-joobie [] has quit [Read error: 104 (Connection reset by peer)]
22:58<knowledgejunkie>I think I've noticed a bug in MainServer::HandleGetNextFreeRecorder when "Avoid conflicts between live TV and scheduled shows" is enabled. The function resets the iterator to the beginning of the encoder list (surely giving the best encoder availble and most likely to be used for recordings), not the next least-worst. Should I raise a ticket for this?
23:00<Anduin>knowledgejunkie: Some of the people most likely to fix it, you will never see on irc.
23:01<knowledgejunkie>Anduin: I'll raise a ticket and in the meantime try and understand how to fix it (I'm not a cpp coder)
23:02<knowledgejunkie>Anduin: what the best way to ask bjm a question? Post on -dev?
23:04<Anduin>knowledgejunkie: A thread is a good idea, but really a ticket is the first place to start (just saying that not all devs are here, a ticket is a good starting point)
23:04<knowledgejunkie>Anduin: thx
23:08-!-turbo [] has joined #mythtv
23:09-!-briand [] has quit [Read error: 110 (Connection timed out)]
23:11-!-foxhunt [] has quit [Remote closed the connection]
23:17<Anduin>knowledgejunkie: I don't see it (just looking at the code), with that setting it should look through all encoders, picking the last, not busy/locked one.
23:19-!-MaverickTech [n=Maverick@] has joined #mythtv
23:19<knowledgejunkie>Anduin: does its behaviour change when LastFreeCard is set? I have only see that taken into account in MainServer::HandleGetFreeRecorder
23:21<Anduin>knowledgejunkie: Which is the were HGNFR goes in some cases
23:21<knowledgejunkie>On my system, I have 4 currently configured cards. I have 'avoid conflicts' enabled, and if I fire up Live TV I get the last encoder (#4) as expected. If I then choose the next tuner, I would expect to get the next least-worse (#3) but it cycles back to #1 (the best encoder, if available)
23:23<Anduin>Ah, yes, I see
23:23<knowledgejunkie>From my looking at the code, I'm guessing this behaviour is because the iterator in HGNFR resets once card 4 is being used
23:24-!-XChatMav [] has joined #mythtv
23:33-!-MavT [] has quit [Read error: 113 (No route to host)]
23:33<Anduin>Yeah, looks like SwitchCards would do it, on the bright side no one uses live TV :)
23:34-!-ahbritto [] has joined #mythtv
23:34<Captain_Murdoch>sphery: those double entries are probably from restores over existing data. we could just put a 'distinct' in that select.
23:35<knowledgejunkie>Anduin: when I do use LiveTV, it would be nice if it worked properly :)
23:35<knowledgejunkie>Anduin: it is the first item on the main menu, after all
23:40-!-MaverickTech [n=Maverick@] has quit [Read error: 110 (Connection timed out)]
23:41<Anduin>knowledgejunkie: Yup, not trying to discourage you form opening a ticket, it looks wrong to me (but that isn't an area of code I've spent much time looking at).
23:42<knowledgejunkie>Anduin: i've opened a ticket (#4931) in any case - hopefully it'll get fixed at some point
23:42<knowledgejunkie>Anduin: thanks for reassuring me I'm not going mad :)
23:45-!-DaedalusX [] has quit []
23:46-!-MaverickTech [n=Maverick@] has joined #mythtv
23:46-!-XChatMav [] has quit [Read error: 113 (No route to host)]
23:59-!-scant [n=scant@] has joined #mythtv
---Logclosed Wed Mar 12 00:00:49 2008