Back to Home / #mythtv / 2007 / 02 / Prev Day | Next Day
#mythtv IRC Logs for 2007-02-19

---Logopened Mon Feb 19 00:00:34 2007
---Daychanged Mon Feb 19 2007
00:00<briand>anyway.. this came to me because I didn't want to change all my ID3 tags to 'McCartney, Paul', etc, and have them display that way..
00:01<briand>so, the database programmer in me decided to 'hide' a sort field in the mix, so the display is unchanged but artists will be able to be alphabetized traditionally
00:02<briand>i dunno... maybe i'm the only one that's this anal-retentive about things like that. :shrug:
00:03<xris>as long as it ignores "the" for me, I'm fine
00:04<briand>well, if we move the current sort to look at artist_sortkey instead of artist_name, it would continue to ignore leading The's
00:04<briand>since the default sortkey fill is equal to the name field.
00:05<xris>I actually don't use mythmusic, anyway
00:05<xris>not until it's smarter about scanning.
00:05<briand>the "the" fixup was okay... but then it still looked like the office telephone extension lists I've seen since moving down south -- alphabetized by first name.
00:06<briand>smarter in what way?
00:06<briand>i think paul added a "search for new" thing in there last week... so it doesn't try to re-import your entire music directory just because you added 10 new mp3 files.
00:07<xris>yeah. should be able to use something like FAM to detect new/changed files/directories...
00:08<xris>but it'll really only be feasible if the backend starts monitoring things
00:08<briand>I've added a "Newly Imported" smartplaylist to my setup, so I can easily bring up all the new files I've imported to check/verify/correct the metadata
00:09<briand>yeah, it is nice... i only wrote the rule... whoever put the smartplaylist thing in there did all the hard work.
00:10<briand>one of the fields it let's you use in the rule is "Date Imported" (which is music_songs.date_entered)
00:11<briand>select that field, between "$DATE - 7" and "$DATE" and you've got everything added to the database in the last week.
00:13<briand> the heck out of scrolling through 15,000+ songs, that's for sure.
00:14<briand>that's just my "regular" batch of mp3 files...
00:14<briand>bunch of top 40 stuff from 1950's thru today... plus every song that ever reached #1 on the Billboard charts, and a couple hundred "one hit wonders"
00:15<briand>i haven't even started ripping my CD collection.
00:15|-|tomimo [] has quit [Remote closed the connection]
00:16|-|kurre2_ [] has joined #mythtv
00:17<briand>anyway.. i should probably get to bed, in an attempt to get to work on time tomorrow morning -- it's after 1:00am here, already. ..and, it'd be in poor taste to be late tomorrow (today) after all they did for me last week. ;)
00:17<briand>nice chatting with you, as always... talk to ya later... :)
00:24|-|tomimo [] has joined #mythtv
00:28|-|clever [] has joined #mythtv
00:29<clever>im looking at fixing a crash in mythvideo but i need to enable debug compiling on the plugins but i dont see a --enable-debug when checking the configure scripts --help
01:24|-|_gnome42 [] has quit [Remote closed the connection]
01:28|-|czth_ [i=dbrobins@nat/microsoft/x-6af3a92cb8ca124a] has joined #mythtv
01:38<xris>blech. this sqlite stuff is WAY too slow to use for web lookups
01:39|-|r3z [n=r3z@unaffiliated/r3z] has joined #mythtv
01:45|-|czth [i=dbrobins@nat/microsoft/x-32be04c6f199b865] has quit [Read error: 110 (Connection timed out)]
01:56|-|r3z` [n=r3z@unaffiliated/r3z] has quit [Read error: 110 (Connection timed out)]
02:13<xris>wtf, suddenly my perl script is always returning an error code of 500
02:13<xris>even when there's no error
02:17|-|eskil [] has quit [Read error: 113 (No route to host)]
02:30|-|Captain_Murdoch [] has quit [Read error: 110 (Connection timed out)]
02:31|-|LLyric [] has joined #mythtv
02:52|-|cattelan_ [] has quit ["This computer has gone to sleep"]
03:06|-|xris [] has quit ["Leaving."]
03:13|-|maddyx [] has joined #mythtv
03:26|-|bio___ [] has joined #mythtv
03:27|-|bio___ [] has left #mythtv []
03:30|-|madfactor [] has quit [Read error: 110 (Connection timed out)]
03:42|-|stuarta [n=stuart@unaffiliated/stuarta] has joined #mythtv
04:16|-|fredl [] has joined #mythtv
04:38|-|JoeXBorn [] has joined #mythtv
04:43|-|DrNickRiviera [] has joined #mythtv
04:47<stuarta>janneg: your latest EIT update means only 1 of my cards can get EIT data
04:48<stuarta>since the both use the same datasource
04:48<stuarta>my preferred way of fixing it would have been to make only one eit scanner and feed all eit update through it.
04:50<janneg>no, each channel is individually locked. please don't tell me that you have eit other for all channels on all multiplexes
04:50<stuarta>yup we do :)
04:50<stuarta>indeed. lets just work towards a single scanner
04:51<stuarta>better in the long run.
04:51<janneg>yes, that's on my todo list
04:51<stuarta>i can live with this while we are in dev, but not through release
04:52<janneg>yeah, sure. It works here nicely since we have only some channels with eit_other
04:53<stuarta>uk is the odd one out though. it's prob the only country where all eit data is cross carried
04:54[~]janneg wonders if making the eit cache static would do the trick (for single backend systems)
04:55<stuarta>not static, more global methinks
04:56|-|JoeyBorn [] has quit [Read error: 110 (Connection timed out)]
04:58<janneg>if all scanning instances share the same eit cache, the locking is only a problem for multi backend systems
04:59<stuarta>think for now, having a single cache per backend will do
05:08<janneg>I think I can make a simple version of the new eit scanner working and commitable in the next days
05:10<stuarta>sure, i'll be around to test if when it's ready
05:11<stuarta>just drop the patch in an email
06:36|-|cattelan_ [] has joined #mythtv
06:39|-|r3z` [n=r3z@unaffiliated/r3z] has joined #mythtv
06:44|-|Dibblah [] has quit [Read error: 113 (No route to host)]
06:55|-|LLyric [] has quit ["Leaving"]
06:56|-|r3z [n=r3z@unaffiliated/r3z] has quit [Read error: 110 (Connection timed out)]
07:34|-|cattelan_ [] has quit ["This computer has gone to sleep"]
07:36|-|Dibblah [] has joined #mythtv
07:38|-|cattelan_ [] has joined #mythtv
07:55|-|cattelan_ [] has quit [Read error: 104 (Connection reset by peer)]
07:57|-|cattelan_ [] has joined #mythtv
08:17|-|cattelan_ [] has quit ["This computer has gone to sleep"]
08:17|-|cattelan_ [] has joined #mythtv
08:29|-|cattelan_ [] has quit [Read error: 60 (Operation timed out)]
08:31|-|Cardoe [n=cardoe@gentoo/developer/Cardoe] has joined #mythtv
08:46|-|jmk [] has joined #mythtv
08:50|-|jablk1 [] has joined #mythtv
08:50<stuarta>janneg: btw. i'm running 12824 and still get the current_picture not initialized errors....
08:51<janneg>stuarta: for new recordings?
08:52<stuarta>erm, they were done last night so, no didn't get to update until this morning
08:53<janneg>that's expected behaviour. I fixed only the position map generation in dtvrecorder
08:53<stuarta>i'm going to put back the commenting out of the cur pict stuff until i get through the backed up commflagging
08:53<stuarta>then i'll try without it.
08:54<janneg>does your frontend hangs after seeing this error?
08:55<stuarta>my mac does almost always, my main one does sometimes
08:55<stuarta>the commflagger always locks itself out
08:55<stuarta>looks like it causes transcodes to error too.
08:56<stuarta>but i only updated this morning, so won't have any new recordings till this evening
08:58<janneg>a backtrace of a locked process would be nice. I can't reproduce the locks
08:59<stuarta>commflagging locks itself out "searching for logo" cause (i think) the decoding thread errors with "current picture not initialized"
09:10<jablk1>know if anyone is working on mac frontrow integration?
09:10<jablk1>sharing myth videos with daap?
09:10<stuarta>funnily enough i was just reading about that.
09:11<stuarta>probably quite low on the list of todo for the mac
09:18<GreyFoxx>Anyone see this before? Compiler did not align stack variables. Libavcodec has been miscompiled -
09:18<GreyFoxx>I just kicked off a transcode and had that in my backend log
09:19<stuarta>ugh... time for a distclean methinks
09:20<GreyFoxx>I did one, and cleared the ccache before that last compile (a week ago)
09:20<GreyFoxx>I've never seen that message before, and this is the first internal transcode I've done in months
09:20<GreyFoxx>so I thought I'd mention it :)
09:28<sphery>briand: re: #3104, you're missing some theme updates...
09:28<sphery>You need to update music-ui.xml in G.A.N.T, blue, and default-wide in mythtv
09:28<sphery>and Titivillius and Minimalist-wide in mythtthemes
09:28<janneg>GreyFoxx: I'll check it, can you create a ticket with system details, gcc version
09:30|-|jgarvey [] has joined #mythtv
09:34<janneg>probably a configure error if the gcc is recent and sane
09:37<GreyFoxx>gcc 3.3.4
09:37<GreyFoxx>but I'll pop something into trac about it
09:40<janneg>that's pretty old, but I'll see that I can do
09:41|-|DrNickRiviera [] has quit ["Leaving."]
09:57|-|okolsi [] has joined #mythtv
09:59<janneg>GreyFoxx: thanks
10:04<okolsi>janneg: have time for quick DVB question?
10:06[~]stuarta listens as well
10:07<okolsi>stuarta, janneg: cosmetic issue.. seeing CRC check fails for stream 0x70 (time, TDT)
10:09<janneg>TDT has no crc
10:09<stuarta>we should add an exemption for it
10:10<okolsi>sorry, could you explain.. Myth now checks it even thou its not present and we should add a speacial case to skip CRC for TDT?
10:10<janneg>I'm pretty sure I covered it correctly
10:11<stuarta>i see those as well, just haven't found the time to find out why.
10:12<okolsi>okay.. this doesn't seem to affect anything.. so I was just curious
10:12<janneg>okolsi: can paste the exact error message
10:12<okolsi>PESPacket: Failed CRC check 0x86160420 != 0xd0bbd269 for StreamID = 0x70
10:12|-|JoeXBorn [] has quit ["be back in a few"]
10:12<okolsi>having two of these EVERY time there is a DVB time related log print
10:13|-|gnome42 [] has joined #mythtv
10:14<janneg>it might be a crc check as pes packet
10:19<okolsi>I have one of those cards that have the CRC etc. bug/feature
10:20<janneg>that doesn't matter. the check is done while pes packet assembly and the HasCRC just doesn't for dvb sections
10:23<janneg>I'll fix that soon
10:24<okolsi>sounds good :)
10:30|-|Cougar [] has quit [Read error: 110 (Connection timed out)]
10:49|-|aevil^aw [] has joined #mythtv
11:00|-|Cougar [] has joined #mythtv
11:05|-|xris [] has joined #mythtv
11:48|-|Captain_Murdoch [] has joined #mythtv
11:57|-|DrNickRiviera [] has joined #mythtv
12:10|-|robthebob [] has joined #mythtv
12:12|-|Saucisson [] has joined #mythtv
12:17|-|gbee [] has quit ["Gone"]
12:23|-|gbee [] has joined #mythtv
12:34|-|xris [] has quit ["Leaving."]
12:34<gbee>think I can probably make the file system side of the music scanner more efficient by taking the mod time of the parent folder into account
12:35<gbee>of course xris leaves 8 seconds before I typed that
12:36|-|CDevMobile [] has joined #mythtv
12:36<gbee>the only thing I don't know, is whether all or at least the majority of systems are consistent in the way folder modification dates work
12:38<gbee>I suppose it's also questionable whether there will be a significant boost by not stat'ing every single mp3
12:40<okolsi>by the way, the filescanner fails if you have music files with non-standard characters (e.g. scandinavic)
12:40<okolsi>actually it is the stat for each mp3 file that fails
12:41<okolsi>for me, it can be fixed by changing something like filename.ascii() -> filename.utf8()
12:42|-|gilroy [] has joined #mythtv
12:42<okolsi>but.. don't know if this is a proper fix
12:42|-|gilroy [] has left #mythtv ["Ex-Chat"]
12:43<okolsi>I'm talking about the MythMusic filescanner if someone wonders
12:53<gbee>that's a long standing problem, or at least not something to do with my recent changes
12:53<gbee>but I've made note of it and it'll get fixed
12:54|-|soulfury [] has left #mythtv []
12:54<okolsi>gbee: okay.. thanks already in advance!
12:59|-|r3z` [n=r3z@unaffiliated/r3z] has quit [Read error: 104 (Connection reset by peer)]
13:16|-|CDevMobile [] has quit [Read error: 110 (Connection timed out)]
13:24|-|gbee [] has quit [Read error: 104 (Connection reset by peer)]
13:28|-|beavis [] has joined #mythtv
13:29|-|gbee [] has joined #mythtv
13:29|-|xris [] has joined #mythtv
13:31|-|JoeyJoeJo [] has joined #mythtv
13:34<xris>Chutt: any chance you can hook kormoc up with commit access? He's been doing a bunch of stuff for mythweb, and I'm apparently not fast enough getting to his patches (plus, he sits a few feet away from me at work so I can slap him if things go wrong).
13:45|-|agungl [] has joined #mythtv
13:46|-|agungl [] has left #mythtv []
13:47|-|eskil [] has joined #mythtv
13:53|-|aevil^aw [] has quit ["Verlassend"]
14:05|-|CDevMobile [] has joined #mythtv
14:06|-|erazor [] has quit [Connection reset by peer]
14:23<gnome42>stuarta: I was thinking 4 days as the limit. ie. Delete anything in 'tvchain' that is older than four days.
14:24<stuarta>sounds reasonable
14:24<gnome42>Are there folks who watch tv for that long? :)
14:24<stuarta>i *seriously* doubt it
14:25<stuarta>i've probably only got that many entries due to all the eit testing i was doing over the weekend...
14:26<gnome42>Yeah, I haven't been doing much testing since I last manually cleaned out the table but I still have 30 entries in there
14:27|-|tomimo [] has quit ["Gotta get going ..."]
14:27<stuarta>mine are probably all title=unknown due to clearing out the entire program table.
14:31<gardengnome>i just wrote "kernels" instead of "girls". i need to get out more.
14:32<gnome42>gardengnome: indeed! :)
14:34|-|CDevMobile [] has quit [Read error: 110 (Connection timed out)]
14:36<sphery>gnome42: Are you making changes in housekeeper.cpp, like CleanupMyOldRecordings() or perhaps adding a new CleanupLiveTVChain() call in the DailyCleanup or something totally different?
14:36<gnome42>void HouseKeeper::CleanupOldLivetvChains(void)
14:36<gnome42>did you already do it?
14:37<sphery>I'm starting to think there should be some code to go through and identify orphaned records in some other tables, too (like recorded{markup,seek}).
14:37<sphery>Seems several people have/think they have a lot of old stuff in there, too.
14:37<gnome42>anything over four days old is removed .. sounds reasonable?
14:38<sphery>I don't have any idea how the LiveTV stuff works (don't use it myself), so mine is not a worthwhile opinion. ;)
14:38<stuarta>i only use live tv for testing :)
14:38<gnome42>sphery: yeah, i hacked up a script to cleanout those tables too. The buildup there didn't seem to bad to me.
14:38<gnome42>yeah, me too. :)
14:39<sphery>Are you deleting the entire chain when you do the delete?
14:39<sphery>(i.e. by chainid)
14:40<sphery>Oh, and no, I haven't already done it. I just happened to have put the DailyCleanup there (per Captain_Murdoch's design) when moving cleanup from mfdb to housekeeper, so I thought it would be a good place for it.
14:40<gnome42>hmm, no I wasn't going to follow chainid, just anything older than four days (which I thought was a huge amount of time for livetv ;0
14:40<gbee>sphery: that's something I suggested the housekeeper should handle, cleaning up tables etc and possibly even doing the work of the optimise script in contrib occassionally
14:40<Chutt>i'd prefer if someone figured out why the chain wasn't getting deleted in the first place.
14:41<gbee>heh - should read everything before posting
14:41<sphery>Here Chutt wants to fix the problem, not the symptom. He'll never work for a drug company... :)
14:42<Chutt>someone could easily have more than enough space for 4 days of live tv.
14:42<gbee>Chutt: tends to be as a result of crashes, I'm not aware of any other circumstances
14:42<gnome42>Chutt: I think they generally are cleaned up correctly. For me they arise mainly when do testing/breaking things.
14:42<gnome42>yeah crashes and stuff.
14:43<gbee>if each chain had a unique identifier, then discontinuities would be easy to identify and cleanup on that basis rather than by age
14:44<stuarta>in tvchain
14:44<gbee>if it's unique and won't be repeated within a reasonable time frame then yeah
14:44<Chutt>it won't ever be repeated.
14:46<gbee>the idea being that if there isn't a programme in chain #123 with an end time in the future we can delete the chain (or something along those lines - I'm not 100% familiar with the tvchain)
14:47|-|kurre2_ [] has quit [Read error: 110 (Connection timed out)]
14:47|-|o_cee [] has joined #mythtv
14:48<o_cee>yey, i got a vps :]
14:48<gnome42>Hmm, ok, I didn't realize the tvchain table was used when the user went back in to re-watch an old livetv recording. Is that what you meant?
14:49<gbee>I'm interjecting opinions on a subject where I'm not in possession of all the facts - It would probably be safer to ignore me
14:50<sphery>So, that's two of us who said we should be ignored... Leaves gnome42 on his own to find out how LiveTV works/cleanup should work.
14:51[~]stuarta joins the camp with only a few pieces of the puzzle
14:52<sphery>I will say that if watching a previously-recorded show that's in the LiveTV group (and was put there by watching from LiveTV) uses the tvchain table, I'd be really surprised.
14:53<gbee>gnome42: I guess what I'm saying is, don't delete entries from the tvchain table on the basis of date alone you need to consider if the chanid is still in use
14:53<gbee>I doubt, like sphery, that the tvchain table plays any part in watching a recorded livetv programme
14:54<gbee>I'd guess that it only applies when watching livetv er.. Live
14:55<gnome42>gbee: Hmm, I understand what you are saying. (Assuming you meant chainid and not chanid :)
14:56<gbee>yeah (always get those two mixed up ;) )
14:56<gnome42>gbee: But. if the chainid is still in use then doesn't that mean that someone has been running livetv for the entire time?
14:57<gbee>some people will want to do that, whether or not we can see a good reason for it
14:58<gnome42>Oh, ok. We gotta accomodate the perpetual livetv watchers. no prob :)
14:58<gnome42>that's where i got confused :)
14:59<gbee>well there is no reason to limit them to 4 days (aside from concerns about their health)
15:00<gnome42>:) OK, I'll see if I can work something out.
15:02<gbee>or you could just ignore me, as I said before ;)
15:04<gnome42>oh, no. I really appreciate your input :)
15:04[~]gbee adds a mod_time column to the music directories table
15:05[~]gnome42 eyeballs 'watching' column in tvchain table - always 0 even when watching ;)
15:07<stuarta>sounds like that bit wasn't implemented...
15:07|-|offset [] has joined #mythtv
15:09<sphery>gnome42: How did you identify records in recorded{markup,seek} to delete?
15:09<gnome42>Chutt: Feel free to wave me off this "cleaning" the tvchain table if you thhink its foolish or something :) I can always look for another corner of the room to sweep up :)
15:09<gbee>chanid, starttime ! in recorded
15:10<sphery>HouseKeeper::CleanupRecordedTables() looks like it would work perfectly--except for the fact that the DISTINCT would probably kill the database for a table the size of recordedseek...
15:10<sphery>Basically, the query becomes:
15:10<sphery>SELECT DISTINCT p.chanid, p.starttime FROM recordedseek p LEFT JOIN recorded r ON p.chanid = r.chanid AND p.starttime = r.progstart WHERE r.chanid IS NULL;
15:11<sphery>Been running it on my system...
15:11<sphery>For a while, now.
15:11<gnome42>sphery: hmm, maybe I went the other way... I looked in recordedseek to identify files that don't exist on disk
15:11<sphery>Wouldn't be good if it were recording.
15:11|-|tomimo [] has joined #mythtv
15:11|-|kurre2 [] has joined #mythtv
15:12<janneg>lol, NVP thinks the video is 30 ahead and behind of the audio
15:12<sphery>The only reason we're doing the distinct is because the query identifies unique chanid/starttimes and then we do DELETE based on those.
15:12<Chutt>gnome42, naw, it's fine, just don't use just the time to decide if it's old or not
15:12<sphery>To work around MySQL 3.x's lack of support for DELETE's with JOINs
15:12<gnome42>sphery: email addy? I can send you the scripts
15:13<stuarta>janneg: ahead *and* behind??? man that is confused
15:15<janneg>yeah, I couldn't believe it first. this is with h.264 HD playback
15:15<stuarta>only h264?
15:15<sphery>6 rows in set (6 min 49.45 sec)
15:15<sphery>Wouldn't want to run that during a recording...
15:15<gbee>or it's bending space-time, or something ....
15:16|-|okolsi [] has left #mythtv []
15:16<gbee>wouldn't really want to run it at all - might be better to handle it in two stages
15:17<sphery>Even without the distinct, it's bad.
15:17<janneg>yes, only h.264. many audio buffer underuns
15:17<gbee>grab distinct starttime, chain in the first query and then search against those in the recorded table (or vice-versa)
15:17<gbee>should be a lot faster than using joins
15:18<sphery>I'm looking at identifying orphans in recordedseek...
15:19<sphery>which has to compare against "NOT IN" recorded.
15:19<sphery>Oh, and I don't know MySQL or anyone else SQL. :)
15:20<gnome42>sphery: Oh, I think I only checkd against non-existant files on disk not in recorded.
15:21<sphery>Yeah. That would be bad when the NFS drops offline... ;)
15:22<sphery>Looking at your scripts, now.
15:23<xris>Chutt: you see my note about kormoc?
15:23<sphery>BTW, recorded{program,rating,credits} are already being cleaned up by HouseKeeper::CleanupRecordedTables()
15:23<sphery>45535 rows in set (6 min 49.53 sec)
15:23<sphery>Same time whether I use distinct or not. Both are unacceptable times.
15:23<gnome42>janneg: re: h.264 perf. did you see that comment about ffmpeg option 'skiploopfilter'? (just FYI)
15:23<Chutt>xris, yeah.
15:23<Chutt>Remind me later
15:24<Chutt>I thought he had it already
15:24<stuarta>Chutt: dunno if j-rod asked, he has svn but not trac access...
15:24<xris>good enough.
15:24<xris>I can probably add him myself. Just wanted to get permission.
15:25<xris>nope, no svn access for kormoc
15:25<janneg>gnome42: which comment? so probably no. but my avformatdecoder is already hacked to skip the loop filter
15:26<Chutt>xris, you have root on the svn vserver, no?
15:26<xris>but I'll let you or Snow-Man handle it. I don't want to muck up Snow-Man's organization, and I know that debian doesn't seem to have the nice user-creation scripts that rh includes.
15:26<Chutt>you could just add him
15:26<Chutt>just 'adduser kormoc'
15:26<Chutt>and then add him to those two groups.
15:26<Chutt>use vigr or whatnot :p
15:26<xris>ah, ok. script is backwards.. it's useradd in rh.
15:27<janneg>stuarta: j-rod is in trac
15:27<stuarta>he was having trouble a few days ago :)
15:28<gnome42>janneg: here it is:
15:28<janneg>I remember, but the trac admin interface lists jarod. probably a password problem
15:28<gnome42>sounds like you got that optimization already :)
15:29<janneg>gnome42: ok, I haven't skimmed trough users in the last days
15:31[~]j-rod wakes up and pays attention
15:31<stuarta>j-rod: you already seem to be in trac
15:31<j-rod>no clue what my login password is for logging into trac
15:32<janneg>the same as for svn
15:32<j-rod>hrm, I'll try again, but I'm pretty sure it wasn't working the other day...
15:32<j-rod>okay, so I'm just a retard, or can't type.
15:32<j-rod>worked just peachy this time
15:33[~]j-rod smacks self
15:33[~]stuarta trouts j-rod
15:34|-|JoeyBorn [] has joined #mythtv
15:34<j-rod>mmm, trout...
15:35[~]j-rod could go for some copper river salmon grilled in a lemon butter sauce
15:36[~]sphery thinks gnome42's approach is better than the existing approach in HouseKeeper::CleanupRecordedTables()
15:36<sphery>(once changed to use recorded, not filesystem)
15:37<gbee>Reconnection to backend server failed <= No idea of the cause, but seems to result in the frontend hanging
15:38<sphery>I think we should modify CleanupRecordedTables() to query recorded{program,rating,credits,markup,seek} for DISTINCT chanid, starttime
15:38<sphery>Then query recorded for DISTINCT chanid, starttime
15:38|-|basdfasdfsadf [] has joined #mythtv
15:38<sphery>Then delete those records from recordedwhatever that don't appear in recorded
15:38<xris>.me is confused. the htpasswd file referenced in the apache config doesn't seem to exist.
15:39|-|basdfasdfsadf changed nick to JoeBorn
15:39<sphery>Even though the DB isn't doing a snapshot match (so the queries occur at different times), since we do the recorded query second, we'll err on leaving stuff that shouldn't be there (but that will be deleted tomorrow)...
15:39<xris>oh, I see. someone named it .htaccess
15:40<Chutt>i never felt like changing it
15:40|-|ReAspired [] has joined #mythtv
15:40<xris>j-rod: has a login there
15:40<sphery>And, querying for DISTINCT chanid, starttime takes much less than 1s (0.1s even on recordedseek)
15:40<Chutt>that's already established :p
15:40<j-rod>has a login where?
15:40<xris>oh, thought you said he didn't
15:40<xris>j-rod: to trac
15:40[~]stuarta offers j-rod more trout
15:40|-|ReAspired [] has left #mythtv ["Leaving"]
15:41|-|asdfadfgdfgof [n=rootmeis@] has joined #mythtv
15:41|-|fredl [] has quit ["Leaving"]
15:41<j-rod>must... pay... more... attention...
15:41<xris>ok, I think that's done
15:41|-|JoeBorn [] has quit [Nick collision from services.]
15:41<j-rod>xris: I'm all good
15:41|-|asdfadfgdfgof changed nick to JoeBorn
15:41<xris>so I've gathered.
15:41<xris>and so is kormoc now.
15:41<j-rod>xris: hey, got any spare socket 940 motherboards out your way?
15:42<j-rod>(and/or, does simech sell any such beast?)
15:42[~]j-rod managed to crack the pcb on his k8n-dl over the weekend, and it no longer boots
15:43<xris>I'll ask
15:45<xris>single/dual, atx/eatx? I'll take that as a "yes".. you should probably just call in at this point.
15:45<j-rod>dual-socket, atx or eatx
15:46<j-rod>I'll poke around the web site some
15:46<j-rod>only I don't see parts listed anywhere, so maybe I do need to call...
15:47|-|asdfasdfgfoo [] has joined #mythtv
15:47<xris>we don't sell individual parts on the website, so you won't find much.
15:48|-|JoeBorn [n=rootmeis@] has quit [Nick collision from services.]
15:48|-|asdfasdfgfoo changed nick to JoeBorn
15:56|-|JoeyBorn [] has quit [Read error: 110 (Connection timed out)]
15:57|-|kuback [] has joined #mythtv
15:57|-|ReAspired [] has joined #mythtv
15:58|-|ReAspired [] has left #mythtv ["Leaving"]
16:02|-|alfredk [n=fredk@] has joined #mythtv
16:02|-|jmk [] has quit ["Leaving"]
16:05|-|alfredk [n=fredk@] has left #mythtv ["Kopete 0.12.2 :"]
16:09<sphery>gnome42: Still here?
16:10|-|kuback [] has left #mythtv ["Ex-Chat"]
16:22|-|aevil [] has joined #mythtv
16:32|-|JoeBorn [] has quit ["do not panic, i will be right back!"]
16:37[~]janneg has proper h264 HD playback. seeking seems to be broken though
16:39<janneg>athlon64 X2 at 2.4ghz is enough
16:39<janneg>with a little bit tuning and another ffmpeg resync maybe 2.2ghz
16:40<stuarta>i suspect you will be sending them patches...
16:40<gnome42>sphery: yup
16:40<janneg>a fresh mplayer checkout uses approx. 10% less cpu
16:42<gnome42>janneg: was there a performance breakthrough? What yielded the best improvements?
16:42<janneg>stuarta: them == ffmpeg?
16:43<janneg>no, I haven't changed libavcodec
16:44|-|LLyric [] has joined #mythtv
16:44<janneg>I only discovered that seeking disturbs the avsync
16:51|-|stoffel [] has joined #mythtv
16:51|-|beavis [] has quit ["Verlassend"]
16:57<janneg>it seems to be a problem with ac3 decoding
16:57|-|jgarvey [] has quit ["Leaving"]
16:59<janneg>the audio pts is after seeking 0 regardless of the position of the stream
16:59<janneg>while the video pts is maintained correctly
16:59|-|Cardoe [n=cardoe@gentoo/developer/Cardoe] has quit ["Leaving"]
16:59<stuarta>that definitely won't help
17:00|-|jmk [] has joined #mythtv
17:00<sphery>gnome42: Have you done anything for cleaning up recordedmarkup or recordedseek?
17:00<sphery>I think we need to put the recordedmarkup and recordedseek cleanup in HouseKeeper::CleanupRecordedTables() with existing cleanup for recordedprogram, recordedrating, and recordedcredits. But, to make it work, we have to change the algorithm I used in CleanupRecordedTables() when I took out the non-MySQL-3-compatible
17:02<gnome42>sphery: only what's in that script
17:03<sphery>I think we could do it like you did--query DISTINCT chanid, starttime from recordedwhatever then query the same from recorded and finally delete from recordedwhatever any records whose chanid and starttime is not in recorded
17:03<gnome42>sphery: oh, did you mean in myth code? nothing at all there
17:03<sphery>Wanted to make sure you hadn't already put something somewhere else.
17:03<sphery>Do you know your MySQL/DB stuff?
17:04<gnome42>sphery: Nope, novice level (no joins :)
17:04<sphery>I don't know whether it's better to select DISTINCT chanid, starttime from recordedwhatever into a temp table and then let MySQL find rows that are in the temp table but not recorded or whether to do the comparison of the two sets of chanid and starttime in C++
17:06|-|stoffel_ [] has joined #mythtv
17:09<gnome42>hmm, my guess is that its better to do it MySQL
17:09<stuarta>time it and see
17:09<sphery>I like that--means I won't write a bad C++ impl :)
17:18|-|stoffel [] has quit [Connection timed out]
17:18<gbee>I'd do it like this -
17:18<gbee>select distinct chainid, starttime from recordedseek;
17:19<gbee>while (
17:19[~]gbee pauses to think
17:20<gbee>select from recorded where chanid=query.chanid, startime=query.starttime
17:20<gbee>if result =0 (no matches) { DELETE FROM recordedseek WHERE blah blah blah }
17:21<sphery>With temp table, I got these results:
17:21<gbee>because we're using MyISAM with the issues of lock contention, that should be better than one single query and I'm betting it will be a lot faster too
17:22<sphery>The number of orphaned records should be small--on the order of the number of shows a person deletes in a single day
17:23<sphery>The number of distinct chanid,starttime in recordedseek will be hundreds to a couple of thousand
17:24<gbee>yeah, I'm not sure there is any advantage to that method - especially because the join on those tables, even a smaller temp table is going to be slow (relatively)
17:24<gbee>but whatever works
17:25<sphery>I can't decide between the temp table and JOIN or the hundreds of queries identifying valid recordings....
17:26<sphery>I'm leaning toward the temp table/join if there's no reason not to use them because we could use the existing code and just add a CREATE TEMPORARY TABLE above it...
17:26|-|Cardoe [n=Cardoe@gentoo/developer/Cardoe] has joined #mythtv
17:27<gbee>btw you have 403 recordings?
17:27<gbee>well 402?
17:28<sphery>Actually, 400. I have 2 orphans
17:28<sphery>Makes testing easier
17:29<sphery>Yeah. I just got another 750GB HDD, giving me a total of 3TB on 2 backends with HDTV only recording. I'm loving Myth... :)
17:29<gbee>quite a few more than I have, at any time I'd guess I have no more than 20-25
17:29<xris>ahh, cool. janneg did get those db changes in place.
17:29<sphery>I need to get a life. I've just been watching lives on TV as a substitute.
17:30<gbee>I mean if I ever get around to buying some larger disks, I'd probably keep a few films around but mostly at the moment I'm recording stuff I plan on watching within 1-3 weeks
17:31<sphery>The sad part is that I haven't watched any of the 400 recordings (I watch and delete.)
17:31<sphery>This weekend I had 437 recordings and I'm "catching up."
17:31<gbee>and usually I'll let some stuff expire without watching (recorded for that rainy day with nothing else to watch)
17:32<sphery>Basically, my backlog gets me through the off-season.
17:32<gardengnome>oops, wrong window.
17:33<gbee>I'd probably record a little more if I had the cable hooked up to mythtv - but I'm getting by without watching anything on cable atm
17:33<sphery>I have Myth record every new series and just today I deleted a bunch of episodes of shows that have been cancelled. By watching long after the premier, I don't get into a show that gets cancelled. :)
17:33<sphery>I'm doing OTA only.
17:34<sphery>Good thing I don't have Food, Discovery, TLC, History, Sci Fi, etc.
17:35<gbee>some of the better stuff coming here from the US is what gets cancelled :) Often I take cancellation to mean that it was just too sophisticated for the general population ;)
17:36<gbee>not 100% true, some of it is just crap
17:36<sphery>Yeah. I still hate Fox for putting Firefly--a show targeting males between 18 and 35--on Friday night and then cancelling it because it had low viewership.
17:39|-|gleesond [] has joined #mythtv
17:40<gleesond>so I am trying to figure out a cheep video capture card that will work with linux any suggestions? I already have svideo working on my main video card
17:41<sphery>gleesond: try #mythtv-users
17:41[~]gleesond WW sorry
17:41|-|gleesond [] has left #mythtv []
17:44|-|robthebob [] has quit [Read error: 104 (Connection reset by peer)]
17:48<gbee>really wish there was a better GPL'd id3 tag library
17:50<janneg>gbee: which does mythmusic use?
17:51<xris>janneg: glad to see those db changes go in. :)
17:52<janneg>yeah, me too. and no complains
17:52<eskil>gbee, which id3 lib would you prefer ?
17:52<janneg>my db schema update took 33 minutes
17:52<gbee>which is the most recently updated, but only supports id3v2.4 writing (2.3 would be better)
17:53<gbee>eskil: that's the problem, one isn't better than the other
17:53<janneg>gbee: what is with
17:53<eskil>gbee, yeah, when searching on goggle, it seems like it's always a trade for which bugs/missing features you want.
17:53<gbee>id3lib apparently has it's share of bugs and is even older
17:53|-|LLyric [] has quit [Read error: 104 (Connection reset by peer)]
17:54<gbee>janneg: have to be honest, I've never come across that one before, which is odd as I've been looking for an alternative for a while
17:54<janneg>it's lgpl but uses afaik also 2.4
17:56<eskil>taglib always looked good, and it's purely C++.
17:57<gbee>I'll experiment with it
17:58<gbee>my problem with 2.4 is that support is still pretty limited - 2.3 is read by almost all players software and hardware
17:59|-|stoffel_ [] has quit ["leaving"]
18:01<gbee>even if we can't find a 2.3 writing lib, I think switching to taglib might be a consideration
18:02<gbee>I think using libid3tag was partially to do with the fact that it shipped with mad (one less dependancy)
18:04|-|monkeyBox [] has joined #mythtv
18:04<monkeyBox>Is there a mythtv bootsplash theme out there? (and perhaps a howto to go along w/ it)?
18:05<briand>there is a #mythtv-users channel....
18:06<briand>gbee: I don't know if it showed up on your radar (yet), but I put in a patch regarding the mythmusic db changes we spoke about last week
18:07<sphery>briand: did you see my message about the missing theme updates?
18:07<gbee>briand: yeah, saw it
18:08<briand>sphery: umm.. no, when did you send it?
18:08<sphery>You'll also need to update music-ui.xml in G.A.N.T, blue, and default-wide themes in mythtv and Titivillius and Minimalist-wide themes in mythtthemes
18:08<sphery>nvm--that's it.
18:09<sphery>Was almost 9 hours ago.
18:10<sphery>I'm only mentioning it as I once got stuck updating a bunch of the themes to prevent segfaults when someone forgot to update the "other" themes after adding a new container to MythGallery.
18:10|-|rtsai1111 [] has joined #mythtv
18:10<briand>ah, okay.. no problem, I can add them and submit a modified patch
18:11<briand>just the themes shipped within the mythtv svn, then?
18:11<sphery>Yours wouldn't be so bad--no segfault--but would mean the UI for changing the value would only be available in themes using defaults music-ui.xml.
18:11<sphery>Which would get confusing when explaining to users how to change the sort order for music.
18:12<briand>true. :)
18:12<briand>i ran into that with eskil's shoutcast patch -- there's no 'edit radio' screen in the MythCenter theme.. so I had to switch to G.A.N.T to edit/add shoutcast streams
18:13<sphery>I did basically the exact same patch as your MythMusic patch for MythVideo before Anduin's major rewrite, but he went with the more-traditional-sorting approach in the rewrite.
18:14<sphery>I understand his reasoning at the time, but it looks like users are pushing for the "full-control" a new sort key gives...
18:14<briand>i think the sorting for video titles would (is? should?) be easier than music artists...
18:14<sphery>Yeah, I actually wrote three different patches for that and I don't care about it myself.
18:15<sphery>I fixed a bug (that prevented multiple same-titled videos from appearing in the list--happens a lot with movies) that happened to be due to the sorting algorithm.
18:15<briand>it would be a nightmare to code a sorting algorithm to produce "McCartney, Paul", "Pink Floyd", and "Edgar Winter Group" from the info usually found in the id3tag
18:16|-|Saucisson [] has quit ["Quit"]
18:16<eskil>briand, my bad, there were a few releases (5.2x) where the mythcenter and others were missing the edit-radio stuff.
18:16<briand>...and, as soon as you hit upon one that worked 99% of the time, some other weirdly named artist/group would happen along and break it.
18:17<sphery>Yeah. I like the idea myself.
18:18<briand>eskil: oh.. no problem. :) it didn't really bother me all that much... I was just pointing out that I had been 'bitten' by the same thing sphery was describing
18:18<gbee>I have to admit, that I aesthetically I don't like having two columns but I can't see a better way of doing it
18:19<briand>it seemed the best way to handle having a 'display name' and a 'sort name', which often do not agree.
18:19<briand>HD real-estate is miniscule compared to the files in question
18:19<gbee>one of those cases which occassionally comes up, where the best way isn't always the prettiest way
18:19<sphery>I got there because someone kept complaining about the sorting algorithm I though most appropriate--case-insensitive--and because the existing sorting code actually said there should be a column in the database specifically for sorting.
18:19<briand>and it gives the end-user ultimate control over how the list(s) is(are) presented
18:20|-|rtsai1112 [] has joined #mythtv
18:20<sphery>So, I did it that way for MythVideo so the other guy could use his broken sorting order if he wanted... :)
18:21<briand>sphery: heheh.. funny you should say that. somebody said in the discussion they preferred having their artists sorted alphabetically by first name.
18:21<sphery>But, since Anduin chose to sort off title in MythVideo using the implementation I liked (case-insensitive), I didn't mind when he didn't use the sort key.
18:21<sphery>Yeah. To each his/her own.
18:22<briand>yep. i'm old enough to realize that mine isn't always the only 'correct' viewpoint
18:22<sphery>Right. Mine is. :)
18:22<gbee>I don't often browse my collection - I tend to use one big playlist with smart random
18:22<sphery>a smart approach, indeed.
18:23<briand>gbee: after i got my tags straightened out, i started playing with the smart playlists...
18:23<gbee>the only time I find myself having to think about what I'd like to play is when trying to choose a playlist which will fit on my mp3 player
18:23<briand>i hear ya.
18:24<briand>find yourself a deal on a Zen Jukebox. I've got a 40G version that I use to tote music back and forth to work
18:24<briand>it'll hold about 6 weeks of continuous music, so it's not like you have to keep reloading it all the time.
18:25<gbee>probably the way to go
18:27<briand>one of the managers at work heard that i fiddle with electronics, and asked me to take a look at his (headphone jack separated from the circuit board; easy fix). i was hooked. surfed ebay and found one with three extra batteries, carrying case, etc ... all for $150, including shipping
18:27|-|rtsai [] has quit [Read error: 110 (Connection timed out)]
18:28<briand>and a charge on one of those batteries usually lasts 2-3 days of playing time (~20 hours)
18:29|-|jmorganson [] has joined #mythtv
18:29<briand>and, i just ran across a linux program to manage it.. gnomad2
18:30<sphery>I'm wondering how bad #3031 (Recording will not commence until PMT is set.) is and whether I should set up a dev box just so I don't get bit by it (my production box is pre-r12619)...
18:35<gbee>ok... that shouldn't have happened
18:36<briand>sphery: where did you leave that message? there's nothing attached to the ticket, and nothing in my mailbox... or, did I miss it in the scroll here?
18:36|-|rtsai1111 [] has quit [Read error: 110 (Connection timed out)]
18:39<gbee>briand: I saw it, but I can't remember where or find it now either
18:41<sphery>It's in #mythtv
18:42<briand>ah... i must have missed it in the scroll. i got it now, tho, and i'll update the patch and submit it this evening
18:42<sphery>I figured I'd put it there in case you saw it before I saw you here.
18:42<briand>'there' is here.. this is #mythtv, isn't it?
18:42<gbee>ahh was at 15:28:03 (GMT)
18:42<sphery>Wasn't worth a ticket comment or e-mail reply
18:42<briand>ah.. ran off the top of my xchat buffer, i guess
18:43<sphery>no awaylog for xchat?
18:43[~]sphery likes irsii
18:43<gbee>thought it was earlier than that, which is why I couldn't find it
18:44<briand>there's probably a plugin for it, sphery, but i haven't really looked
18:44<sphery>Oh. Mine tells me anywhere my nick appeared while away when I come back from away.
18:45<sphery>I agree, though, that there are way too many plugins to go through for any IRC program available today.
18:45<briand>xchat will do that, the channel tab changes color when my nick is mentioned
18:45<briand>maybe it 'un-highlights' after it rolls off the top of the scroll, tho
18:47|-|Shmattie [] has joined #mythtv
18:52<briand>sphery: should I put the Minimalist-wide and Titivillus music-ui.xml changes in a separate patch? they're not in the mythtv SVN, they're in myththemes
18:54<sphery>I would--separate patch, but same ticket.
18:55<briand>okay, no prob.. and i'll add blue, default, and G.A.N.T to the main patch
18:56<sphery>thx. As a Minimalist-wide user, I appreciate your doing the changes for my theme, too. :)
18:57<briand>i'll make you the same offer I've made to others -- donate a 61" flatscreen HDTV to me, and I'll use that as my base system. ;)
18:58<sphery>Sorry. Mine is a 67" DLP. If I had the 61" flat-screen, ...
19:00|-|rtsai [] has joined #mythtv
19:02|-|PointyPumper [] has quit [Read error: 104 (Connection reset by peer)]
19:03|-|PointyPumper [] has joined #mythtv
19:11|-|jams [] has quit [Read error: 104 (Connection reset by peer)]
19:11|-|jams [] has joined #mythtv
19:13|-|monkeyBox [] has quit ["Leaving"]
19:17|-|rtsai1112 [] has quit [Read error: 110 (Connection timed out)]
19:21<Captain_Murdoch>janneg: the string stuff was in the recordedmarkup code because Qt v3.1.x didn't support QString::toLongLong().
19:22<Captain_Murdoch>not saying it still needs to be that way, just commenting because I saw the discussion in scrollback.
19:24|-|DrNickRiviera [] has quit ["Leaving."]
19:24<janneg>Captain_Murdoch: I figured something like that but I checked and qt 3.3 is required now. so I thought it's save to remove that
19:27|-|aevil [] has quit [Read error: 113 (No route to host)]
19:29|-|jmorganson [] has quit ["Chatzilla 0.9.77 [Firefox]"]
19:29|-|Shmattie [] has left #mythtv ["Leaving"]
19:32<Captain_Murdoch>yeah, that's why I didn't say anything when I saw the commit log because I thought we required 3.3 now already. and after 0.21 we'll require MySQL v4.x so some of the other stuff can be cleaned up if people want to.
19:34|-|cattelan [n=cattelan@] has joined #mythtv
19:35<janneg>but the programinfo stuff was just something I cleaned up while I was checking if my schema change requires other changes
19:48|-|jd86 [] has joined #mythtv
19:55<janneg>Captain_Murdoch: btw I discovered why by key frame advancing in the edit screen skips key frames. the frontend seeks to (current frame + 15) but max key frame distance for pal is twelve
19:55<janneg>I think you have a ticket for this issue
19:55<janneg>I'll fix that when I find some time
20:04<Captain_Murdoch>ok. for some reason I thought It also occurred when I tested on NTSC, but maybe it didn't and that's why I hadn't fixed it yet. :)
20:19<janneg>it can occur if the key frame interval is less than 18 (not 15) frames
20:20<janneg>ok, fixed my h264+ac3 seeking problem
20:24[~]xris wishes he could figure out why h264 just doesn't work for him.
20:24<xris>ok, time to go home, yay!
20:24|-|xris [] has quit [""]
20:36|-|MrGandalf [] has quit [Read error: 104 (Connection reset by peer)]
20:44|-|[R] [n=ron@gentoo/user/ginsu-squirrel] has joined #mythtv
20:44|-|[R] [n=ron@gentoo/user/ginsu-squirrel] has left #mythtv ["Leaving"]
20:59|-|gnome42 [] has quit [Read error: 110 (Connection timed out)]
20:59|-|gnome42 [] has joined #mythtv
21:10|-|xris [] has joined #mythtv
21:17|-|ReAspired [] has joined #mythtv
21:18<ReAspired>well I'm back at trying again, I created another account on this machine, I only got big error, and don't see how backend gets started
21:18<xris>ReAspired: I think you're in the wrong channel
21:18<ReAspired>dooh yea
21:18|-|ReAspired [] has left #mythtv ["Leaving"]
21:23|-|LoneShadow [] has joined #mythtv
21:24|-|LoneShadow [] has left #mythtv []
22:16|-|jd86 [] has quit [Remote closed the connection]
22:28|-|JoeyJoeJo [] has quit ["Leaving"]
22:35|-|GrimSleeper [] has joined #mythtv
22:38|-|GrimSleeper [] has left #mythtv []
22:40|-|Nem^1 [] has joined #mythtv
22:56|-|Nem^ [] has quit [Read error: 110 (Connection timed out)]
22:56|-|Nem^1 changed nick to Nem^
23:12|-|Anduin [] has quit ["Leaving."]
23:13|-|poptix [] has quit [Read error: 128 (Network is unreachable)]
23:32|-|_nero_ [n=nero@unaffiliated/nero] has quit [Read error: 110 (Connection timed out)]
23:35|-|_nero_ [n=nero@unaffiliated/nero] has joined #mythtv
23:58|-|NSLU2-IRC [] has joined #mythtv
23:58|-|NSLU2-IRC changed nick to |Atum|
---Logclosed Tue Feb 20 00:00:44 2007