:: #mythtv

Daily chat history

Current users (90):

20QAAN1DK, aloril_, andreax1, Anduin, Anssi, anykey__, bbc581, beata_, Beirdo, brfransen, caelor, Captain_Murdoch, Chutt, clever, coling, Computer_Czar, Cougar, dagar, Dave123, davide, dblain, dekarl1, dlblog, eharris, elmojo, elvum, foobum, foxbuntu, gbutters, ghoti, Gibby, gregL, GreyFoxx, h7252, hads, highzeth, holomntn, iamlindoro, ikonia, J-e-f-f-A, j-rod|afk, jams, jannau, jarle, jcarlos_, JEDIDIAH__, joe__, jpabq, jpabq-, jstenback, justpaul, jwhite, kc, kenni, knightr, kormoc, kurre, laga, leprechau, mag0o, markk_, Mousey, mrand, MythBuild, MythLogBot, okolsi, pheld, PointyPumper, poptix, purserj, reynaldo, rhpot1991, rooaus1, skd5aner, sphery, Splat1, stuarta, stuartm, superm1, sutula, tgm4883, ThisNewGuy, tomimo, tris, vontrapp, wagnerrp, weta, xris, ybot, _charly_
Tuesday, February 1st, 2011, 00:05 UTC
[00:05:00] markk_: stuartm: just catching up. pretty sure I'm still seeing that issue – will check again today.
[00:05:32] stuartm: markk_: thanks
[00:19:53] h7251 (h7251! has quit (Ping timeout: 264 seconds)
[00:20:11] jmartens (jmartens! has quit (Ping timeout: 240 seconds)
[00:21:22] XChatMav (XChatMav! has joined #mythtv
[00:24:04] MavT (MavT! has quit (Ping timeout: 248 seconds)
[00:51:23] MavT (MavT! has joined #mythtv
[00:52:05] kormoc is now known as kormoc_afk
[00:54:28] XChatMav (XChatMav! has quit (Ping timeout: 248 seconds)
[01:01:48] XChatMav (XChatMav! has joined #mythtv
[01:02:27] markk_: stuartm: confirmed – still seeing it. video list isn't shown until there is some form of 'user intervention' – either a keypress or a window focus type event
[01:04:10] jmartens (jmartens! has joined #mythtv
[01:04:36] MavT (MavT! has quit (Ping timeout: 248 seconds)
[01:09:12] knightr (knightr!~knightr@mythtv/developer/knightr) has quit (Ping timeout: 250 seconds)
[01:14:45] highzeth (highzeth! has quit (Remote host closed the connection)
[01:26:39] Mousey (Mousey! has quit (Quit: Leaving)
[01:30:02] gigem_ (gigem_!~david@mythtv/developer/gigem) has quit (Remote host closed the connection)
[01:30:27] gigem_ (gigem_! has joined #mythtv
[01:30:28] gigem_ (gigem_! has quit (Changing host)
[01:30:28] gigem_ (gigem_!~david@mythtv/developer/gigem) has joined #mythtv
[01:49:20] kormoc_afk is now known as kormoc
[02:01:25] knightr (knightr!~knightr@mythtv/developer/knightr) has joined #mythtv
[02:15:55] Steve_Goodey (Steve_Goodey! has joined #mythtv
[02:18:48] markk_: sphery: just looking at my (extensive) list of tickets :) – would you care to take a look at #9213 ?
[02:19:40] jmartens1 (jmartens1! has joined #mythtv
[02:20:56] jmartens (jmartens! has quit (Ping timeout: 255 seconds)
[02:24:43] sphery: markk_: sure, I think I can handle that one.
[02:26:38] markk_: sphery: excellent – thanks. and when you've got that sorted...
[02:29:03] sphery: heh, wait--don't let it get out that I'm taking on new tickets, now, or everyone will start to get ideas (and my, how mythtv code quality would suffer :)
[02:37:39] elmojo (elmojo!~elmojo@unaffiliated/elmojo) has quit (Remote host closed the connection)
[02:39:24] elmojo (elmojo!~elmojo@unaffiliated/elmojo) has joined #mythtv
[02:41:28] ** kormoc runs UPDATE Tickets SET Owner 'sphery'; **
[02:42:11] jya (jya!~avenardj@mythtv/developer/jya) has quit (Quit: jya)
[02:43:07] Steve_Goodey (Steve_Goodey! has quit (Remote host closed the connection)
[02:53:03] vontrapp: kormoc: I can do it without changing the scheduler query
[02:54:04] vontrapp: but i either have to take over the "record new expire old" option and rename it, or add an additional option, in which case it really wouldn't make sense when both are checked, so one would take precedence
[02:55:06] vontrapp: for the proof of concept i'm going to hack it into the existing option
[02:55:49] vontrapp: when I'm convinced it works, then I'll look into creating a new option or perhaps changing it from a boolean option to a enum-style option
[02:58:17] vontrapp: the tv frontend already treats it as though it were a multi-option, but the web interface shows it as a boolean checkbox option
[03:50:48] elmojo: does anyone remember how to check out 0.23-fixes?
[03:51:03] elmojo: nm, I forgot it's in git
[04:51:04] elmojo: markk_: I found one problem with LiveTV regarding broken seeking when a new transition occurs – unfortunately it looks like a few other problematic cases are still present
[05:14:44] XChatMav (XChatMav! has quit (Ping timeout: 248 seconds)
[05:40:35] danielk22 (danielk22!~danielk@ has joined #mythtv
[05:45:00] danielk22: stuartm: re my comment on #9536, I say that as the guy who enabled blocking deletes while a preview is running. The UI downside of my pursuit of correctness is worse than the problem it solves. Ideally we'd fix it so no chaff is left behind, but just reverting to not blocking deletes on a previewgen inuse entry would be better than the current behavior.
[05:53:11] jmartens (jmartens! has joined #mythtv
[05:53:51] jmartens1 (jmartens1! has quit (Ping timeout: 240 seconds)
[06:03:26] elmojo: anyone know what ticket(s) exist for the LiveTV seeking issues?
[06:05:40] elmojo: markk_: here's a fix for the LiveTV seeking between different programs problems ->
[06:05:50] gigem (gigem! has quit (Ping timeout: 240 seconds)
[06:19:54] gbutters1 (gbutters1! has quit (Ping timeout: 250 seconds)
[06:22:51] markk_: elmojo: thanks – does that work for seeking forward and back? does looking at the tv_chain->HasNext call
[06:30:55] gigem (gigem! has joined #mythtv
[06:30:55] gigem (gigem! has quit (Changing host)
[06:30:55] gigem (gigem!~gigem@mythtv/developer/gigem) has joined #mythtv
[06:38:10] jmartens (jmartens! has quit (Read error: Connection reset by peer)
[06:48:21] Beirdo: sigh
[06:48:37] Beirdo: mailman is such a pain when you wanna migrate it
[06:50:09] Beirdo: the mail config is now setup to send mailman to the old server, but I missed one line in the postfix configs... and it was setting the from host wrong in one particular case.. which I think the commit hook used to mail
[06:50:34] Beirdo: so it bounced two messages about 20min ago. SHould be fixed now.
[06:50:41] Beirdo: trac was working though
[06:50:54] Beirdo: gonna force a readme change to see this hit
[06:53:02] Beirdo: OK, fixed
[06:53:03] elmojo: markk_: should fix everything including forward/backward jumps, ffwd/rew, seeking across boundaries
[06:53:32] Beirdo: please excuse the repeat messages, going to tell github to resend the last couple commits which should get the missed one
[06:53:35] Beirdo: or two
[06:54:29] markk_: elmojo: if it does all that, I'll be posting you a case of my favourite alcoholic beverage!
[06:54:33] markk_: (babycham)
[06:54:57] Beirdo: there it is. it was markk's revert commit.
[06:55:00] elmojo: markk_: heh, it wasn't enough trouble to deserve that :)
[06:56:37] elmojo: I reset fftime, rewindtime in JumpToProgram – dunno if that's optimal or not – maybe better in a more common function used by JumpToProgram
[06:58:13] andreax (andreax! has joined #mythtv
[07:01:10] elmojo: any one opposed to increasing the short timeout for socket connections from 7 secs to 10 secs?
[07:01:43] elmojo: it's needed for LiveTV and HD-PVR to work reliably
[07:03:02] Beirdo: No objections here
[07:03:04] gbutters (gbutters! has joined #mythtv
[07:03:09] Beirdo: is it really that long? wow
[07:03:18] h7251 (h7251! has joined #mythtv
[07:03:41] elmojo: Beirdo: I've hit close to 9 seconds on a transition here
[07:03:59] Beirdo: I suppose on resolution change it does take a bit
[07:04:01] elmojo: basically the player calls OpenFile then the socket connects waiting for the data
[07:04:19] elmojo: it's not a resolution change, just a file change
[07:04:23] Beirdo: well, getting it working is worth teh extra up to 3s :)
[07:05:01] Beirdo: wow. that's obnoxiously long to close and reopen a file, but meh, there it is
[07:05:26] elmojo: yeah, jpabq seemed surprised it took that long too
[07:05:37] markk_: I guess that's the downside of an external box
[07:05:51] NightMonkey (NightMonkey!debian-tor@pdpc/supporter/professional/nightmonkey) has quit (Ping timeout: 240 seconds)
[07:06:04] elmojo: most if not all other recorders accomplish a LiveTV transition in less than 2 seconds easy
[07:06:06] Beirdo: yeah, and an H.264 encoder likely takes a certain amount of time for startup too
[07:06:33] Beirdo: it is what it is. :)
[07:07:46] elmojo: a few seconds every hour or so during a program break isn't that big of a deal and it's only a problem if you are watching LiveTV in real time
[07:09:10] markk_: unless the broadcaster is a couple of minutes out with their timing – and it's the cliffhanger ending that gets interrupted :)
[07:09:51] Beirdo: hehe.
[07:09:59] Beirdo: let the screaming commence.
[07:18:42] danielk22: Beirdo: The timeout change doesn't bother me, but any backend call routinely taking more than 2 or 3 seconds needs to have either the implementation or the API rewritten... :|
[07:20:19] yojimbo-san (yojimbo-san!~yojimbo-s@ has joined #mythtv
[07:20:30] yojimbo-san (yojimbo-san!~yojimbo-s@ has left #mythtv ()
[07:21:07] Beirdo: makes sense
[07:22:42] kormoc: We should profile these backend requests sometime
[07:22:50] kormoc: some of them take a really long time
[07:25:33] h7252 (h7252! has joined #mythtv
[07:27:16] h7251 (h7251! has quit (Ping timeout: 272 seconds)
[07:31:00] Beirdo: kormoc: yeah, sounds like a good plan
[07:31:46] markk_: elmojo: I knew my beer was safe :0
[07:38:49] areeda (areeda! has joined #mythtv
[07:40:53] areeda (areeda! has left #mythtv ()
[07:49:54] areeda (areeda! has joined #mythtv
[07:57:59] h7252 (h7252! has quit (Ping timeout: 255 seconds)
[07:59:26] h7251 (h7251! has joined #mythtv
[08:14:02] Goga777 (Goga777! has joined #mythtv
[08:28:11] andreax1 (andreax1! has joined #mythtv
[08:28:59] areeda (areeda! has left #mythtv ()
[08:29:58] andreax (andreax! has quit (Ping timeout: 246 seconds)
[09:40:50] Goga777 (Goga777! has quit (Remote host closed the connection)
[09:41:17] dserban (dserban! has joined #mythtv
[09:45:33] stuartm: danielk22: there is a compromise that I've been considering which would keep down the number of stray images, well actually two slight variations on the same theme – if we delete the recording immediately without any checks that improves the usability, any preview completion events we subsequently receive for recordings which no longer exist can trigger a DELETE_PREVIEW event
[09:48:07] stuartm: alternatively we don't delete immediately, we simply remove the recording from the visible list, mark it as pending delete and then when the preview event arrives we check the recording status, deleting it if required – this is the easier option
[09:49:28] stuartm: either way, if the user exits from watch recordings before the preview event arrives we won't be able to delete the image generated, but there would be substantially fewer orphaned images
[09:50:36] stuarta: unless you make the backend responsible for the deletion
[09:50:51] rooaus1 (rooaus1! has joined #mythtv
[09:50:56] rooaus (rooaus! has quit (Ping timeout: 255 seconds)
[09:51:00] stuartm: of the recording?
[09:51:17] stuarta: i guess it would have to be everything
[09:51:25] stuarta: previews as well
[09:51:39] stuarta: so the frontend just submits requests to delete
[09:51:57] stuartm: it currently deletes everything, but at the request of the frontend, if we ask it to delete the recording before the preview image has been written then that image won't get cleaned up
[09:51:58] stuarta: it's the backend that fires up the preview gen isn't it?
[09:52:28] stuartm: the frontend doesn't delete anything itself
[09:52:35] stuarta: right.
[09:52:52] stuarta: so the way i see it, the backend has received a request to delete the recording
[09:53:01] stuarta: it knows it's in use by the preview gen
[09:53:14] stuartm: stuarta: ah, I see what you are saying
[09:53:15] stuarta: to it should get the event from the preview gen that it has finished
[09:53:24] stuarta: and then clean up
[09:53:31] stuartm: yes, that's a better idea
[09:53:46] stuarta: make the backend responsible for all deletion.
[09:53:49] stuarta: :)
[09:57:07] stuarta: either that or it learns how to signal the preview gen to give up, and then clean up
[10:01:57] jamesba (jamesba! has joined #mythtv
[10:26:10] andreax1 (andreax1! has quit (Read error: Connection reset by peer)
[10:27:02] andreax (andreax! has joined #mythtv
[10:40:28] andreax1 (andreax1! has joined #mythtv
[10:40:54] andreax (andreax! has quit (Ping timeout: 276 seconds)
[10:46:21] andreax (andreax! has joined #mythtv
[10:49:50] andreax1 (andreax1! has quit (Ping timeout: 260 seconds)
[10:52:05] h7251 (h7251! has quit (Ping timeout: 276 seconds)
[10:52:13] andreax (andreax! has quit (Ping timeout: 265 seconds)
[10:54:24] andreax (andreax! has joined #mythtv
[10:58:37] MaverickTech (MaverickTech! has joined #mythtv
[11:05:03] Guest64714 (Guest64714! has quit (Remote host closed the connection)
[11:05:54] 20QAAN1DK (20QAAN1DK! has joined #mythtv
[11:29:26] danielk22: stuartm: stuarta: I don't think that last proposal would delete the file if the preview generator fails... One reason you might want to delete a file is because it is so fubarred that it immediately crashes video playback and hence the preview generator.
[11:32:49] danielk22: We could just delete all previews that don't have a matching recording every few days...
[11:36:02] stuartm: danielk22: that was a proposal sphery made some months back, a cleanup process in the housekeeper
[11:39:16] stuarta: well if the previewgenerator crashes surely we should get a signal back to that effect and can take action?
[11:44:36] danielk22: stuarta: Sure, but the code is already complex. On multiple occasions, subtle bugs have been introduced because it takes some time to grok it. If we can engineer a solution that doesn't introduce more complexity and avoids touching a complex bit of code that means saving time on implementation, debugging, and on time spent on future needed modifications to the code.
[11:46:04] stuarta: i think what we came up with is good for recordings that don't crash previewgen
[12:08:22] h7251 (h7251! has joined #mythtv
[12:15:50] Dave123-road (Dave123-road! has quit (Ping timeout: 240 seconds)
[12:19:27] Dave123 (Dave123! has quit (Ping timeout: 240 seconds)
[12:19:37] dserban (dserban! has quit (Ping timeout: 240 seconds)
[12:24:02] knightr (knightr!~knightr@mythtv/developer/knightr) has quit (Ping timeout: 240 seconds)
[12:24:55] knightr (knightr!~knightr@mythtv/developer/knightr) has joined #mythtv
[12:29:25] bbc581 (bbc581! has joined #mythtv
[12:53:49] highzeth (highzeth! has joined #mythtv
[12:56:22] danielk22 (danielk22!~danielk@ has left #mythtv ()
[12:58:06] Dave123 (Dave123! has joined #mythtv
[13:03:22] jya (jya!~avenardj@mythtv/developer/jya) has joined #mythtv
[13:21:43] Dave123 (Dave123! has quit (Ping timeout: 240 seconds)
[13:27:12] Dave123 (Dave123! has joined #mythtv
[13:51:51] andreax (andreax! has quit (Read error: Connection reset by peer)
[13:52:40] andreax (andreax! has joined #mythtv
[13:57:05] andreax (andreax! has quit (Ping timeout: 255 seconds)
[14:33:43] markk_: stuartm: I seem to be going around in circles here. is there a way to create/generate/send actions directly to the main window? I don't want to send keypresses etc – straight actions like "UP", "DOWN" etc
[14:35:40] jcarlos_ (jcarlos_! has joined #mythtv
[14:36:28] jcarlos (jcarlos! has quit (Read error: Connection reset by peer)
[14:37:52] elmojo: markk_: why is you beer safe? :)
[14:39:44] ** stuarta hides his beer **
[14:39:57] markk_: elmojo: it's no longer safe – I drank it:) did a little live tv test with your patch applied – still had some horrible issues. the player seems to be completely losing track of where it is :(
[14:42:55] elmojo: markk_: oh no! you sure you applied the patch and installed – just makeing sure because it should have at least made things much better
[14:44:57] elmojo: could you see if you are hitting that condition that Jiri posted to the ticket for #9023 (player_ctx->tvchain->JumpToNext(true, 1);)?
[14:52:52] elmojo: I guess you passed out....
[14:56:15] j-rod|afk is now known as j-rod
[15:25:47] h7251 (h7251! has quit (Ping timeout: 265 seconds)
[15:26:45] Jordack (Jordack! has joined #mythtv
[15:37:10] jya (jya!~avenardj@mythtv/developer/jya) has quit (Ping timeout: 240 seconds)
[15:40:33] h7251 (h7251! has joined #mythtv
[15:57:00] gigem_ (gigem_!~david@mythtv/developer/gigem) has quit (Remote host closed the connection)
[15:58:02] gigem_ (gigem_!~david@mythtv/developer/gigem) has joined #mythtv
[15:59:40] danielk22 (danielk22!~danielk@ has joined #mythtv
[16:03:31] andreax (andreax! has joined #mythtv
[16:05:23] jya (jya!~avenardj@mythtv/developer/jya) has joined #mythtv
[16:10:06] stuartm: markk_: in short, no, there is no way to do that at present
[16:13:34] MaverickTech (MaverickTech! has quit (Ping timeout: 272 seconds)
[16:14:06] vontrapp: i hacked something up last night, and at first pass it seems to work
[16:14:40] vontrapp: i had one show that wanted to always record upcoming episodes, but I had to leave at that point so didn't get to looking at airdates or if it even had them
[16:15:25] vontrapp: i need to figure out exactly what to do when there is no airdate (i think just not record) or where there's no airdate on existing recordings but is one on the upcoming recording
[16:15:36] stuarta: sounds more like duplicate detection = no in the recording rules
[16:15:42] vontrapp: then there's how to enable that option
[16:18:36] vontrapp: while i was in there, i thought of having it keep track of how many were left for the max recordings instead of just full/not full
[16:19:13] jhatch (jhatch! has joined #mythtv
[16:19:19] vontrapp: so that it would show only _one_ episode as will record and then the rest as max recorded when there's only one slot left
[16:19:37] vontrapp: so i hacked that up too, but turns out the recordings come out of the query in random order, so it didn't work as expected
[16:20:42] vontrapp: damn, i forgot to eat breakfast :(
[16:32:59] vontrapp: stuarta: what do you mean?
[16:33:58] stuarta: "< vontrapp> i had one show that wanted to always record upcoming episodes" <- to me that sounds like you should set the recording rule to not do duplicate detection
[16:34:30] stuarta: anyway i need to head off
[16:34:32] stuarta: back later
[16:35:37] vontrapp: oh, maybe you didn't see what i was talking about last night. i'm hacking it to record past max recordings if the new recording has an older airdate than existing recordings
[16:35:50] vontrapp: the one series was always (seemingly) passing that test
[16:36:26] vontrapp: possibly could have just been that a recorded episode WAS newer than all the others.
[16:36:50] vontrapp: i'll check it tonight, and then get into the expiring logic, so it deletes the right ones
[16:37:30] vontrapp: what do you guys think about the max-recordings tally, is it worth ordering the scheduler query?
[16:38:03] vontrapp: even then conflicts would still represent incorrect information, though not incorrect behaviour
[16:52:51] jcarlos_ (jcarlos_! has quit (Remote host closed the connection)
[17:04:12] elmojo: danielk22: are you against raising the short timeout socket a few seconds? I was hoping to have as many LiveTV failures fixed for the 0.24.1 release and the HD-PVR recorder requires the timeout to be increased.
[17:05:12] elmojo: I'm not sure if there is anything we can do.... hopefully jpabq can have a look at some point
[17:13:02] jmartens (jmartens! has joined #mythtv
[17:24:57] jcarlos_ (jcarlos_! has joined #mythtv
[17:24:58] sphery: danielk22 / stuarta: My solution for ("Orphaned preview images, again") is to store location of preview images in the database as part of the schema change ( . . . e_schema.png --they'll be just another mediafile, but without streaminfo, videofile, videomarkup, videoseek). Once that's in ...
[17:25:05] sphery: ... place, there will be a housekeeping job to delete orphaned mediafiles (which will also include things like fanart, banners, backgrounds, etc.--as well as original recording and transcodings and ...). I'm waiting on 2 more parts before I start putting the schema in place and transitioning to it, but I could hurry them.
[17:27:10] sphery: In the meantime, though, I think it would be fine to just let the images be orphaned for now. Part of the transition will require a function to find all previews and match them with recordings (which will identify and clean up any orphans found). I can put the preview find/cleanup code in sooner, if you like, and just run it as a daily job (and then modify it to actually write info to mediafile when we transition)..
[17:27:47] sphery: benefit of that approach is that it would allow closing #8471 sooner rather than later.  :)
[17:27:48] jhatch (jhatch! has quit (Quit: Leaving)
[17:30:28] SteveGoodey (SteveGoodey! has joined #mythtv
[17:38:48] jamesba (jamesba! has quit (Quit: Leaving)
[17:55:38] dserban (dserban! has joined #mythtv
[18:01:58] natanojl (natanojl! has joined #mythtv
[18:34:17] Mousey (Mousey! has joined #mythtv
[18:43:20] kc (kc!~Casper@unaffiliated/kc) has quit (Ping timeout: 276 seconds)
[18:50:11] andreax1 (andreax1! has joined #mythtv
[18:52:01] andreax (andreax! has quit (Ping timeout: 240 seconds)
[18:56:21] RDV_Linux (RDV_Linux! has quit (Remote host closed the connection)
[18:56:57] kc (kc!~Casper@unaffiliated/kc) has joined #mythtv
[19:01:30] jmartens1 (jmartens1! has joined #mythtv
[19:02:12] danielk22: elmojo: No, I was just pointing out that it's hiding a bug not fixing it.
[19:02:16] jmartens (jmartens! has quit (Ping timeout: 255 seconds)
[19:02:50] danielk22 (danielk22!~danielk@ has quit (Quit: Leaving.)
[19:21:59] stoffel (stoffel! has joined #mythtv
[19:22:28] davide (davide! has joined #mythtv
[19:26:34] gigem_ (gigem_!~david@mythtv/developer/gigem) has quit (Ping timeout: 255 seconds)
[19:28:20] jya (jya!~avenardj@mythtv/developer/jya) has quit (Quit: jya)
[19:53:18] stoffel (stoffel! has quit (Remote host closed the connection)
[20:09:21] stuartm:
[20:09:30] stuartm: oh ffs
[20:10:40] stuartm: tgm4883, superm1: any idea why the 0.24-fixes myth packages are reporting a non-existant sha1 hash in the version info?
[20:15:06] kormoc: stuartm, didn't a bunch of our hashes get renumbered?
[20:15:46] stuartm: About three weeks back, but not in the last few days as far as I'm aware?
[20:16:21] stuartm: unless someone is doing forced rebases which are strictly verboten
[20:16:41] stuartm: or forced pushes or whatever they are called
[20:17:19] stuartm: that hash I linked above is the one reported by the very latest ubuntu -fixes package
[20:17:27] j-rod is now known as j-rod|afk
[20:34:13] tgm4883: stuartm, hmm, not sure, i'll have to check on it in a bit
[20:36:03] tgm4883: stuartm, from the looks of it, looks like there is an extra g at the beginning of it
[20:36:14] tgm4883: should be
[20:36:58] stuartm: tgm4883: ah, that's my fault then
[20:37:02] tgm4883: which is correct in the packaging, but incorrect in the actual version
[20:37:05] stuartm: thanks
[20:37:12] tgm4883: nah, it might be something, i'm checking it
[20:38:28] superm1: stuartm, they shouldn't be...
[20:38:50] tgm4883: superm1, i'm checking now, but it's 15 min download on this slow connection
[20:39:29] tgm4883: superm1, the packaging number is correct, it's the version string when querying the frontend/backend
[20:39:35] tgm4883: i'm assuming via mythfrontend --version
[20:39:58] superm1: it's just capturing it like this:
[20:40:00] superm1: DESCRIBE=`git describe` ;\
[20:40:23] superm1: which looks like busted output to me
[20:40:33] superm1: on an old branch i have checked out it spits out: v0.24-38-g11ee9c5
[20:41:34] skd5aner (skd5aner! has quit (Read error: Connection reset by peer)
[20:41:38] sphery: yeah, that's standard git describe ("The hash suffix is "-g" + 7-char abbreviation for the tip commit of parent")
[20:41:47] superm1: so there's no problems then right?
[20:41:49] skd5aner (skd5aner! has joined #mythtv
[20:42:11] sphery: don't think so
[20:47:33] stuartm: yeah, it's my fault, I didn't realise that it appended a 'g' to the start of the hash
[20:47:52] stuartm: sphery: shouldn't that be 'hash prefix'?
[20:49:26] sphery: stuartm: heh, well, it was talking about the suffix of the describe, which is the hash suffix, which has a g prefix :)
[20:49:53] stuartm: heh, yeah, guess that makes sense
[20:51:25] superm1: maybe i'm just bikesheding, but i think it makes more sense to just put the hash in that field rather than the version, and some arbitrary number that's supposed to be measuring distance to a commit a 'g' and the hash
[21:00:19] tgm4883: bikesheding?
[21:09:03] sphery: the number passed a tag isnice in that it allows you to see that v0.24-38-g11ee9c5 is /much/ older (100 commits older) than v0.24-138-g14bfdc3
[21:09:55] sphery: s/passed/past/
[21:10:13] Steve_Goodey (Steve_Goodey! has joined #mythtv
[21:11:37] tgm4883: sphery, i'll agree with that, that was a good thing about svn
[21:13:20] superm1: the same type of thing could be accomplished by including a build stamp
[21:13:32] superm1: tgm4883,
[21:15:36] tgm4883: I see
[21:16:08] tgm4883: I do think something that that should come back. Much easier to see people are way out of date than having to look it up on git
[21:16:57] superm1: well at least for ubuntu packages the source package build date is included in the dpkg version, just not in mythbackend --version or mythfrontend --version
[21:17:36] Intrepd (Intrepd! has joined #mythtv
[21:19:27] Intrepd: Hello, I think I've found a problem with how MythTV handles PCR in an MPEG2TS in an odd case, I'm not sure the best way to report it. Mailing list, Ticket or here?
[21:22:14] tgm4883: Intrepd, IIRC, the correct method is mailing list until you get confirmation from others that it's actually a bug, then a ticket
[21:22:22] sphery: superm1: I'll admit that repo (not build) timestamps are more useful than numbers that increment at variable rates
[21:22:35] Intrepd: Basically if the PCR is transmitted in the Video PID, but in a packet that contains no payload, MythTV seems to drop it. Which is not the best thing to do
[21:22:40] Intrepd: tgm4883, thanks
[21:24:42] tgm4883: sphery, I could see how timestamps would be useful in that scenario, but from my experience, the users that care about what version they are running care more about the git checkout version (variable increments) rather than the timestamp of when it was actually built
[21:31:51] dserban (dserban! has quit (Ping timeout: 240 seconds)
[21:34:44] natanojl (natanojl! has quit (Ping timeout: 240 seconds)
[21:35:32] stuartm: the --version output is more for us and use in bug reports than users
[21:38:05] stuartm: build dates are problematic since a user might be building a very old revision today, the build date isn't a solid indicator of how old the code is
[21:53:23] dekarl1 (dekarl1! has joined #mythtv
[21:57:12] sphery: right, I don't know if there's a way of getting a "repo" date (i.e. last change date), but that would be more useful
[21:57:18] sphery: than a build date, that is
[22:05:41] stuartm: that can be parsed out of the git log output, but that's messy
[22:06:12] stuartm: and it would need reformatting
[22:08:14] MaverickTech (MaverickTech! has joined #mythtv
[22:10:35] Steve_Goodey (Steve_Goodey! has quit (Remote host closed the connection)
[22:11:58] SteveGoodey (SteveGoodey! has quit (Remote host closed the connection)
[22:16:30] stuartm: sphery: nice, we need more of that sort of thing
[22:16:59] sphery: stuartm: heh, only found it since I was clueless about how the commands were supposed to be used :)
[22:17:11] sphery: ignorance is a wonderful fuzz tester
[22:24:02] iamlindoro: If that's so then I have fuzz testing in excess
[22:28:48] jmartens1 (jmartens1! has quit (Quit: Leaving.)
[22:29:42] reddn (reddn! has joined #mythtv
[22:36:07] vontrapp: personally, i think <version>-<commits> is just fine, though it could do without the final -g<hash>
[22:36:48] vontrapp: but the hash could be useful too, just a sanity check that you are actually looking at the right commit/tree
[22:41:13] kormoc: <commits> being what exactly?
[22:41:34] sphery: the #commits past tag in git describe
[22:41:48] kormoc: is that immutable?
[22:42:35] kormoc: ooh, I see... hrm... wouldn't that have collisions on forks?
[22:42:58] kormoc: (%s/forks/branches/ ?)
[22:44:00] reddn: hey, for anyone that is up to answer.. im very intrigued by the support and overall care that goesinto a sweet ass project like this. i am getting off my a to start to learn to program and to maybe contribute one day. now i've read a lot on the websites about beginning programming, so to ease the transistion from anything else, im thinking of starting with c, or should i go straight to c++?
[22:51:51] vontrapp: kormoc: yes, it would collide in forks, hence the -g<hash> on the end
[22:52:40] vontrapp: reddn: either one should be fine, I would highly recommend spending some quality time up front with memory management and pointers, whatever tutorials and reading material you can get your hands on until you really grok it
[22:52:55] vontrapp: from then on, it's smooooth sailin' ;)
[22:53:05] kormoc: vontrapp, so we couldn't do without the -g<hash> then?
[22:53:17] Beirdo: kormoc: not really
[22:53:21] vontrapp: no... not if you have forks
[22:53:54] vontrapp: it would still carry information, how old the build is in terms of commits, but it wouldn't tell you what fork you're (they're) in
[22:53:55] Beirdo: v0.25-pre-300 could be on any branch past the v0.25-pre tag
[22:54:31] Beirdo: without specifying which precise commit, there will be times when it's not unique without it
[22:58:43] vontrapp: Beirdo: yeah, but it is better than v0.25-pre-<date>, IMO
[22:59:31] Beirdo: both are incomplete without the precise hash number though
[23:00:33] Intrepd (Intrepd! has quit (Remote host closed the connection)
[23:01:51] stuartm: the joke of it is that unless building from a clean tree, the version info could be completely useless, I might have dozens of local commits which throw off both the count and hash
[23:02:42] stuartm: we can only hope to make the best of it
[23:02:44] Beirdo: how so?
[23:03:34] reddn: vontrapp thanks... i've read a little on c so far, pointers want to make me shoot my self in the eye.. thanks for the input. i shall continue
[23:04:06] Beirdo: if you have local commits then the hash in the version info will not be publically available.
[23:04:28] Beirdo: which means we can't support you
[23:05:17] Beirdo: jsut the same as if it says -dirty (or using svn... 12345m)
[23:05:28] stuartm: Beirdo: which was my point, if you have local commits we're unable to determine what version you are running
[23:06:11] Beirdo: we'll still know what branch they are on, and that it's custom code. That's all we need to know to say "we can't support your custom code"
[23:06:12] stuartm: Beirdo: well with the svn style version we could still see where in the timeline your version sat
[23:06:23] Beirdo: true.
[23:07:15] stuartm: in the past we did support people with local patches, so long as they could say those patches were not touching code related to the bugs they were reporting (and we trusted them to know this)
[23:07:22] Beirdo: if people are using custom trees, they'd have to give us access to read their tree to be able to help them
[23:07:47] Beirdo: or they can tell us what public commit they are based on, and we can do the best we can
[23:07:59] Beirdo: oh, I just learned a new cool command.
[23:08:17] Beirdo: git branch --contains 54dde8617
[23:08:29] Beirdo: tells you what branch(es) that commit is on
[23:11:15] MaverickTech (MaverickTech! has quit (Ping timeout: 260 seconds)
[23:12:54] stuartm: fwiw I didn't raise the issue to score yet more points against git, I'd be genuinely happy if git was more forthcoming with information that can be used to create a useful version string
[23:13:01] Beirdo: yeah
[23:13:07] Beirdo: I understand :)
[23:13:38] Beirdo: I think as it is, it's pretty useful, but yeah, if people have local revisions that we can't see, it has its issues too
[23:14:23] ** Beirdo is JUST about to try something... scary **
[23:14:29] stuartm: it would be helpful if we could know that the user is running 2dfn3s which is 101 commits from tag 0.26 + 5 additional commits which are not in origin
[23:14:52] Beirdo: gonna try to back-export our git repo to svn
[23:15:00] Beirdo: yeah, THAT would be useful :)
[23:15:00] stuartm: and that is information which git knows, it tells me different bits and piece of that via various commands e.g. status
[23:15:56] stuartm: e.g. "Your branch is ahead of 'origin/master' by 1 commit."
[23:16:02] Beirdo: yup
[23:16:18] Jordack (Jordack! has quit ()
[23:16:42] clever: i think hg had something like that
[23:18:04] Beirdo: I think we could make our own script to do it, given time and energy
[23:19:04] vontrapp: stuartm: like v0.25-pre-101-5–2dfn3s
[23:19:31] vontrapp: git itself won't spit out that exact input for you, but I'm sure it would be possible to get that exact info through some scripting
[23:19:49] Beirdo: actually, it never will give that precise output
[23:20:00] vontrapp: *exact output, sorry
[23:20:05] Beirdo: due to the SHA1 snippet being invalid :)
[23:20:13] vontrapp: haha
[23:20:21] Beirdo: there's no n or s in hexidecimal
[23:20:33] Beirdo: but yeah, something like that
[23:20:41] vontrapp: i just copied stuartm's... ;)
[23:20:42] Beirdo: I would append the new data to the end
[23:20:58] vontrapp: v0.25-pre-101-<hash>-5?
[23:21:13] Beirdo: not put it in the middle... that way we might be able to even get it into official git-describe at some point
[23:21:19] vontrapp: but you'll still have to modify 101, because git describe is still gonna want to output -106-
[23:21:31] Beirdo: so?
[23:21:35] Beirdo: put 106
[23:21:41] vontrapp: 106–5 then?
[23:21:51] Beirdo: and if there's unpushed, say how many are unpushed
[23:22:03] Beirdo: it will still be usable
[23:22:07] ** Beirdo shrugs **
[23:22:12] clever: looks like i can easily get # Your branch is ahead of 'origin/master' by 1 commit. from 'git status'
[23:22:14] Beirdo: back to my exporting hell :)
[23:22:26] kormoc: but meaningless if the origin repo is not ours
[23:22:42] clever: yeah, depends what you cloned from
[23:22:42] vontrapp: only problem then is, what defines "unpushed" or *the* branch for that matter?
[23:23:12] stuartm: I mashed the keyboard to fake a hash, so sue me ;)
[23:23:12] kormoc: Beirdo, so about that whole going back to svn thing... ;)
[23:23:24] vontrapp: perish the thought!
[23:23:34] clever: just embed a git log from the branch tag to HEAD
[23:23:43] clever: then there wont be any confusion
[23:23:44] Beirdo: kormoc: I'm working on trying to export our current stuff back to SVN
[23:24:05] kormoc: Beirdo, the entire concept of having both svn and git in a read/write setup I think is just insane
[23:24:10] Beirdo: I'm sure it will take several attempts before I can get something that works solidly
[23:24:18] Beirdo: kormoc: we have no choice
[23:24:37] kormoc: Beirdo, as much as I want to go back to svn, if we're gonna keep git as a writable target, my vote is to keep it git only, as svn will just keep getting broken
[23:24:41] holomntn (holomntn! has quit (Ping timeout: 264 seconds)
[23:24:59] Beirdo: kormoc: I hear you. I'm not the one to convince there :)
[23:25:14] kormoc: I just don't understand how we'll ever keep svn sane with a git merge
[23:25:14] h7252 (h7252! has joined #mythtv
[23:25:20] Beirdo: the problem is, just as many people will be alienated by dumping git as by dumping svn
[23:25:21] stuartm: kormoc: jannau and others were working exclusively with git for months before we switched the main repo, it would appear it can be done
[23:25:43] kormoc: stuartm, but not committing to it for svn to suck in
[23:25:55] kormoc: stuartm, svn to git is easy enough, git to svn is not
[23:25:57] h7251 (h7251! has quit (Ping timeout: 246 seconds)
[23:26:07] clever: git svn dcommit?
[23:26:08] Beirdo: I have a potential solution for that, but it needs testing
[23:26:23] kormoc: stuartm, and anytime any rebase happens, svn needs to be resynced and everyone will need to recheck it out
[23:26:24] stuartm: Beirdo: I think that might be a little overdramatic, _everyone_ here signed on as a developer when we were using svn, that was ok by them at that time
[23:26:27] Beirdo: and it needs testing for a while before we depend on it
[23:27:09] kormoc: stuartm, branch merges have to be handled extremely carefully as it can cause dupes to be going to svn
[23:27:35] kormoc: it's really a non-trivial issue given git's... flexibility and... design... decisions...
[23:27:38] Beirdo: for now, we are using git... until we can at *least* find a way to export the current git stuff back to svn flawlessly
[23:27:53] clever: Beirdo: dcommit seems to work for me
[23:27:56] Beirdo: but I *am* trying to find a way to make this work
[23:28:09] Beirdo: clever: dcommit is not as foolproof as you think
[23:28:23] clever: what problems does it cause?
[23:28:26] kormoc: I've talked to a few smarter-then-i people who have tried it. They said they just ended up ditching the inbetween history
[23:28:36] stuartm: kormoc: rebasing is already disallowed and as we've seen it has bad consequences even in a git-only setup
[23:28:38] Beirdo: I know. :)
[23:28:51] kormoc: stuartm, but doesn't mean it won't happen
[23:29:07] stuartm: kormoc: it won't if it means losing commit privs
[23:29:10] kormoc: stuartm, and if we decide we're keeping both sources in sync, we have to know what to do if it does happen
[23:29:44] stuartm: screw up the tree on pain of death
[23:30:22] kormoc: I just don't like counting on someone not making a mistake
[23:30:34] Beirdo: that's true regardless of VCS
[23:30:45] Beirdo: we had a few fun messups in SVN too.
[23:31:15] kormoc: Beirdo, meh. you can't (by default) destroy history in svn. its' allways recoverable
[23:31:17] stuartm: yup, git just potentially magnifies any fallout
[23:31:20] Beirdo: but I'm trying to see what the options are before we commit to anything
[23:31:36] Beirdo: you can't destroy history in git without noticing it eihter
[23:31:55] Beirdo: cryptographically protected history
[23:32:21] stuartm: kormoc: I'm not exactly championing a dual-repo setup, but we've reached a stalemate – despite only using git for a month some people have made it a condition of their continued contribution, we have to find a compromise
[23:32:30] Beirdo: the problem is when you work on a local branch and then cherry-pick or rebase, and comments use the old SHA1... it's not fun
[23:32:31] kormoc: I actually don't buy that. You can alter branch tips without causing any warnings and have them pulled down silently from my understanding
[23:32:38] Beirdo: as stuartm say yesterday
[23:32:42] Beirdo: saw rather
[23:32:50] reddn (reddn! has quit (Ping timeout: 240 seconds)
[23:33:09] Beirdo: once it has been pushed, you can't change it without people noticing
[23:33:13] holomntn (holomntn! has joined #mythtv
[23:33:30] kormoc: stuartm, I know. The problem is the other side make the same conditional requirement. I'm just thinking for the project's sake we may have to lose a side in exchange for sanity
[23:34:13] kormoc: Beirdo, adding to a tip just causes it to come down as a 'new' commit
[23:34:14] stuartm: the last rebase we saw break all the links from tickets etc, that's not good – and it's why I suppose that rebasing is frowned upon
[23:34:47] Beirdo: how is that "changing history"?
[23:34:55] Beirdo: that's for kormoc :)
[23:35:14] Beirdo: adding a new commit on the end of a branch is not changing history, it's committing something new
[23:35:50] Beirdo: so I'm confused as to what you mean here, I guess
[23:36:18] Beirdo: stuartm: yeah, rebasing once the stuff has been linked to/published in any way is painful and sucky
[23:36:47] kormoc: hrm. there was some weird conditional issue with that I had read that if a branch gets a new commit and you rebase on the master after it's been merged it, that commit will silently get put into the main branch, but I'm failing to recall why it was an issue
[23:37:02] stuartm: kormoc: if it came to that, and I hope really that it does not, then the maths are simple – 6 of the top 8 contributing developers voted for a return to svn, and one abstained ...
[23:38:31] Beirdo: oh crap, I think I wedged it ;)
[23:38:32] Beirdo: heh
[23:38:37] Beirdo: that doesn't bode well
[23:39:16] Beirdo: if we can't find a way to keep both in sync, my proposal is to go back to SVN, but run git the way we did before, but officially
[23:39:29] Beirdo: which is quite likely the path we will have to take
[23:39:52] jya (jya! has joined #mythtv
[23:39:52] jya (jya! has quit (Changing host)
[23:39:52] jya (jya!~avenardj@mythtv/developer/jya) has joined #mythtv
[23:39:56] Beirdo: as kormoc has pointed out, bidirectional resyncing is difficult if not bordering on impossible
[23:40:25] Beirdo: the main issue with doing that is manually or automagically exporting all our post-svn changes back to svn
[23:40:52] Beirdo: and if that needs to be done manually, it will be a time consuming effort, with much squashing and rebasing in the process
[23:41:13] Beirdo: which means that the git side will get more linear and need re-pushing
[23:41:26] Beirdo: so... you can see the fun involved :)
[23:41:59] Beirdo: this is why I'm trying to test offline on my devel box to see what path we need to take, and to get a good leg up on the process, etc.
[23:42:21] Beirdo: we can't have a half-assed transition (again) or we will implode into a pile of rubble.
[23:42:44] Beirdo: make sense?
[23:42:55] stuartm: the way I see it, many of the benefits of git still apply if it's only used locally – e.g. merging in a branch etc, from there at most you only need to create a patch, apply to a clean svn tree and commit
[23:43:10] Beirdo: true, it can be used that way
[23:43:34] stuartm: for those who don't seem to mind the additional work created by git, an additional step isn't going to be a deal-breaker
[23:44:39] Beirdo: meanwhile, I have an option or two to investigate. This one's really not being too friendly to me yet
[23:45:12] Beirdo: but it might just be my half-baked way of trying to make it work
[23:45:12] Beirdo: hehe
[23:46:03] reddn (reddn! has joined #mythtv
[23:46:06] stuartm: yes, you lose the individual commits which contributed to the branch as a whole, but that's not a great loss in my opinion, a single commit with a concise commit message is easier to parse than dozens of commit messages detailing all the bug fixes, debugging and other crap which happened along the way
[23:47:14] stuartm: anyway, let's all hope for a happy ending ;)
[23:47:45] xris: stuartm: yeah. squashing merges is often nice, as long as you don't ever intend to do any more work on the branch. otherwise, they confuse merging.
[23:48:18] Beirdo: yeah, if anyone knows of any other svn<->git solution walkthroughs, please feel free to email me with them
[23:48:21] stuartm: xris: I'd guess you can just re-branch from master after the first merge and continue from there?
[23:49:02] xris: stuartm: yeah. squashed merge should be "final".. if you want to keep working on the same topic, you should create a new branch off of master at that point.
[23:50:17] Beirdo: I'll give this one another day or two of hacking at it to see IF it will work for us at all
[23:51:20] xris: because it creates a "new" sha, it confuses things if you ever try to sync up with that point in your branch again. same with cherry picking. they're meant as one-time things, and really confuse merge tracking on branches.
[23:51:35] Beirdo: aye
[23:51:52] cocoa117 (cocoa117! has joined #mythtv
[23:52:47] stuartm: so if you cherry-pick from a branch, you might have problems merging that branch later?
[23:53:35] Beirdo: it will try to merge it again, but that should turn into a null operation
[23:53:47] Beirdo: as it's not a conflict to merge identical changes
[23:54:19] vontrapp: it should be possible to recover even from a crazy rebase on the main repo, using git reflog
[23:54:59] Beirdo: for intermediate/advanced users, sure :)
[23:55:00] vontrapp: but, if you stay with git, the rules should go something like this
[23:55:06] vontrapp: NEVER EVER rebase the main branch, EVER
[23:55:08] Beirdo: for a git newbie... heck no
[23:55:11] xris: right, but cherry picking can cause some confusion when reading the history, etc. imho they're best used only for backporting.
[23:55:22] xris: vontrapp: except for pull --rebase\
[23:55:37] vontrapp: xris: on your OWN branch, yes, you can pull --rebase
[23:55:37] Beirdo: yeah, for copying to a branch you know will never be merged in
[23:55:45] Beirdo: like master vs fixes/0.24
[23:55:51] xris: vontrapp: local master, yes. but never push -f of master
[23:56:20] xris: even when git helpfully suggests that you should try it.
[23:56:26] vontrapp: Beirdo: you only need one advanced user to fix a screwup
[23:56:38] Beirdo: heh
[23:56:41] vontrapp: and then flog the offender profusely
[23:56:46] Beirdo: nah
[23:56:58] vontrapp: ;)
[23:57:14] reddn (reddn! has quit (Ping timeout: 240 seconds)
[23:57:22] Beirdo: said advanced user doesn't have ssh access to the other person's computer, hence no access to the reflog, nor git itself
[23:57:40] vontrapp: if you create a bug fixing branch that is public, and you wish to sqaush that history back onto the main branch, then a squash merge commit _onto_ the main branch should work just fine
[23:57:46] stuartm: xris, Beirdo: so what about merging back fixes from a branch, you notice a problem whilst working a feature in a branch and decide that it really needs to be fixed ASAP in master – the branch as a whole is incomplete and not ready for merging?
[23:58:15] vontrapp: Beirdo: the main repo will have it's own reflog, from which you boot out the bad commit and revert to the good commit
[23:58:16] xris: stuartm: what I would do: create new branch on master, fix the bug, then merge that bugfix branch both to master and my project branch
[23:58:26] xris: vontrapp: don't have access to the main repo
[23:58:36] vontrapp: who doesn't?
[23:58:42] Beirdo: any of us
[23:58:43] xris: vontrapp: anyone. it's on github
[23:59:15] cocoa117 (cocoa117! has quit (Quit: Leaving)
[23:59:15] stuartm: I know that's something the version of SVN we are using does well, since commits are linear cherry-picking just applies the same change to both branches and that won't affect a future merge (I was playing with that just before we switched to git)
[23:59:42] vontrapp: you can have a backup repo or two from github then
[23:59:47] xris: stuartm: with git, cherry picking creates 2 commits rather than just putting that one commit in 2 places
[23:59:47] Beirdo: ugh
[23:59:50] Beirdo: anyways...

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