MythLogBot@irc.freenode.net :: #mythtv

Daily chat history

Current users (82):

aloril, andreax, Anduin, Andy50, Anssi, anykey_, beata, brfransen, Captain_Murdoch, cesman, Chutt_, clever, coling, Computer_Czar, Cougar, dagar, danielk22, Dave123, dlblog, eharris, elmojo, elvum_, f33dMB, FinnTux, foobum, foxbuntu, ghoti, Gibby, gigem, gregL, GreyFoxx, highzeth, hobiga, iamlindoro, ikonia, j-rod|afk, jams_, jannau, jarle, jcarlos, joe__, jpabq, jpabq-, jstenback, justinh, jwhite, kc, ke^_, knightr, kormoc, kurre, laga, mag0o, Malard, MavT, mike|2, mrand, MythBuild, MythLogBot, M|ckael_, NightMonkey, okolsi, PointyPumper, poptix, purserj, reynaldo, sailerboy, Seeker`, skd5aner, Snow-Man, sphery, stuarta, sunkan, sutula, tgm4883, tomimo, tris, Unhelpful, weta, xris, ybot, _charly_
Monday, April 25th, 2011, 00:08 UTC
[00:08:45] PointyPumper (PointyPumper!~pintlezz@190.244.73.13) has quit ()
[00:13:35] randomuser (randomuser!~pete@209.181.6.183) has joined #mythtv
[00:13:43] randomuser (randomuser!~pete@209.181.6.183) has left #mythtv ("Leaving")
[00:15:02] PointyPumper (PointyPumper!~pintlezz@190.244.73.13) has joined #mythtv
[00:51:54] davide_ (davide_!~david@mythtv/developer/gigem) has quit (Remote host closed the connection)
[00:52:21] davide_ (davide_!~david@host103.16.intrusion.com) has joined #mythtv
[00:52:21] davide_ (davide_!~david@host103.16.intrusion.com) has quit (Changing host)
[00:52:21] davide_ (davide_!~david@mythtv/developer/gigem) has joined #mythtv
[01:10:39] XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv
[01:10:47] larzen (larzen!~gregf@S010600188b390af1.cg.shawcable.net) has left #mythtv ()
[01:13:25] MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 250 seconds)
[01:13:41] mrand (mrand!~mrand@ubuntu/member/mrand) has quit (Ping timeout: 252 seconds)
[01:15:37] mrand (mrand!~mrand@ubuntu/member/mrand) has joined #mythtv
[01:43:03] MaverickTech (MaverickTech!~MaverickT@220.233.86.111) has joined #mythtv
[01:45:03] XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 250 seconds)
[01:58:39] jya: jpabq: ping
[01:58:57] jya: I sent you an email with a patch, let me know if it fixes the playback profile for you...
[02:00:37] ptriller (ptriller!~ptriller@194.105.98.15.dynamic.cablesurf.de) has quit (Read error: Connection reset by peer)
[02:05:36] jpabq: jya: with that patch, I get: http://pastebin.com/aivfhQeL
[02:05:56] jya: already tried ?
[02:06:20] jya: ??
[02:06:23] jya: wtf?
[02:08:25] jpabq: :) Didn't take long to compile since there wasn't any header changes.
[02:08:26] jya: can you post a backtrace ? no idea why Qt would throw an exception error
[02:09:06] jpabq: That will require a while to compile, since I will have to change from opt to debug flags.
[02:09:34] jya: how do you even create a playback profile and put your particular recording in that profile?
[02:11:08] jpabq: Playback profiles are defined under Setup->Video->Playback groups
[02:11:35] jya: humm.... this error can only happen if the "MULTICHANNEL" define isn't set
[02:12:09] jpabq: Personally, in my recording rules, I tell it which playback group to use. In theory, you can also define a playback group to automatically trigger based on show name, but I have never done that.
[02:12:19] jya: just noticed that if you timestretch 7.1 content , it will crash
[02:15:01] jya: what about this patch?
[02:15:01] jya: http://pastebin.com/U99W5Sy8
[02:18:37] jpabq: Still crashes the same way. BT coming up.
[02:20:57] jya: this one adds more log with -v audio
[02:22:13] jya: only thing I can think of is that the number of channels is > 6
[02:23:47] jya: if you change your audio config to 5.1 , does it work better?
[02:25:19] jpabq: Here is the BT: http://pastebin.com/rNQiLQ9u
[02:27:29] jpabq: Still crashes with it set to 5.1 instead of 7.1.
[02:29:48] jpabq: Still crashes the same way, with "Stereo PCM only"
[02:35:36] jpabq: jya, could it be because Dolby Digital is "2 channel", but when timestretch is activated it goes to 5.1 channel (PCM) — and that is not accounted for somewhere in there?
[02:36:20] mrand (mrand!~mrand@ubuntu/member/mrand) has quit (Ping timeout: 276 seconds)
[02:38:54] mrand (mrand!~mrand@ubuntu/member/mrand) has joined #mythtv
[02:40:21] jya: with my last patch, there's some logs about how many channels it's calling timestretch with
[02:40:25] jya: can you post it ?
[02:47:53] Andy50 (Andy50!andy50@173.23.19.191) has joined #mythtv
[02:50:19] Beirdo: jya: do you happen to have any MHEG samples?
[02:51:22] Beirdo: don't know all where it's transmitted, but it's certainly not here, so I figured I'd try .AU :)
[02:56:41] chaorain (chaorain!~chaorain@72.42.81.72) has joined #mythtv
[02:57:10] chaorain (chaorain!~chaorain@72.42.81.72) has left #mythtv ("Ex-Chat")
[03:00:44] elmojo: Beirdo: I believe I have some MHEG samples
[03:05:19] Beirdo: cool, would it be possible to get one fo about 100MB or so?
[03:07:30] elmojo: sent PM
[03:22:13] Beirdo: now I just need to figure out how to reproduce the crash, and I can see if it's fixed :)
[03:22:40] MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv
[03:25:30] MaverickTech (MaverickTech!~MaverickT@220.233.86.111) has quit (Ping timeout: 260 seconds)
[03:25:48] Beirdo: OK, I can make it crash with mythavtest
[03:25:50] Beirdo: perfect
[03:30:20] Beirdo: much much better
[03:30:44] Beirdo: well, I won't claim all of MHEG works, but with the fix I have here, at least it doesn't immediately crash
[03:32:32] Dave123 (Dave123!~dave@cpe-66-66-127-3.rochester.res.rr.com) has joined #mythtv
[03:34:14] mycoDA: bierdo – i think mheg mpeg2ts is UK, isnt here in au
[03:34:35] Beirdo: K. Good to know :)
[03:39:38] XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv
[03:41:51] MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 248 seconds)
[03:42:52] jpabq: jya, you say "this one adds more log with -v audio", but I don't see any extra logging in http://pastebin.com/U99W5Sy8
[03:47:09] jpabq: elmojo, on #8706, apply that to frontend, backend or both?
[03:48:44] elmojo: jpabq: that's a good question... I think it's just backend but I'd suggest both
[03:48:56] elmojo: jpabq: are you seeing the pauses too?
[03:49:07] frankbean (frankbean!~frankbean@c-98-203-229-76.hsd1.wa.comcast.net) has quit (Quit: Textual IRC Client: http://www.textualapp.com/)
[03:49:21] jpabq: Yes. I have for a while now. I do *not* use nfs.
[03:49:54] jpabq: I especially notice a pause when watching a show, and a new recording starts up, but I also get them randomly during playback.
[03:50:25] elmojo: seems to be happening here on occasion (no nfs either) – but I upgraded about the time my house got struck by lightening and I had to rebuild all my machines – I figured it was hardware but with many reporting the same it's definitely a regression of some sort
[03:50:38] jpabq: elmojo, I am running trunk. RingBuffer.cpp is gone?
[03:51:01] elmojo: renames to ringbuffer.cpp I thinki
[03:53:39] jpabq: yup
[03:54:04] jpabq: Probably won't be able to install it on the backend tonight.
[03:56:08] Beirdo: elmojo: OK, checked in my fix which seems to fix that crash. Let's hope more of MHEG works now :)
[03:56:54] elmojo: jpabq: for some reason my HD-PVR doesn't record Army Wives on a regular basis – I wonder if it's a mythtv issue or maybe the HD-PVR has good taste
[03:58:04] jpabq: :)
[03:58:46] elmojo: Beirdo: should that fix be sent upstream as well?
[03:59:16] Beirdo: I'm not sure it's in their code
[03:59:27] Beirdo: mpegts.c is a mess of a merge
[03:59:33] jpabq: elmojo, I have a patch which detects "recording glitches" (i.e. poll timeouts) with the HD-PVR, and tells Myth to re-record that episode (assuming it airs again). It works, but my HD-PVRs have become stable again, so I have not needed it. I should polish it up, and commit it, though.
[03:59:44] Beirdo: we can look at doing so, though
[04:00:18] Beirdo: the problem is, upstream they changed one direction, and our custom code had changed another
[04:00:24] elmojo: jpabq: too bad Army Wives doesn't re-air the new episodes :(
[04:00:51] Beirdo: it was a painful merge (as it apparently has been for several merges)
[04:00:52] jpabq: elmojo, may help you anyway, since it would not detect a complete miss, just a glitch.
[04:00:58] jpabq: elmojo, not
[04:05:30] elmojo: jpabq: I think the ringbuffer change is helping – only time will tell – I believe the patch reverts to the previous behavior but it's been awhile since I looked at the code
[04:06:24] elmojo: a ringbuffer regression makes sense too because higher backend activity would make it worse
[04:09:28] Beirdo: now I need food, then to look at the deadlock fun
[04:10:00] ** elmojo hands Beirdo a can of Red Bull **
[04:10:08] Beirdo: hehe
[04:10:24] Beirdo: I tend to do coffee instead, but I appreciate the sentiment :)
[04:10:52] Beirdo: those deadlocks can be quite the bear to track down, and then worse to fix
[04:11:39] Beirdo: the joys of using threads :)
[04:30:34] Captain_Murdoch: dblain when you get a chance, can you give an opinion on http://pastebin.com/uBNtg9c8 it's a potential patch to allow translating in HtmlServerExtension for .qsp, .qjs, .html, and .js files using a "<?translatable text?>" construct in those files.
[04:53:48] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[05:16:27] superm1: Beirdo, have you been seeing any build failures since that ffmpeg merge a few days ago? i've noticed the last 3 auto-daily builds were failing for both lucid and natty for trunk on both i386 and amd64 (and they're both done from what should be clean source checkouts daily) https://launchpadlibrarian.net/70351126/build . . . BUILD.txt.gz
[05:22:18] Beirdo: they compile fine on the buildbot
[05:22:50] Beirdo: at least in 64-bit mode. I'll get the 32-bit slave back up tomorrow, hopefully
[05:23:17] Beirdo: you sure the build dir was actually cleaned out?
[05:24:01] Beirdo: they ran into a similar issue with OSX where a few .o files remained behind and then got linked in when they weren't supposed to or something like that
[05:24:53] superm1: well the machines building the source package don't build binary packages ever
[05:25:16] superm1: they just daily pull the latest git updates and rebuild a new source package that is kicked to a different box to do binary
[05:25:44] superm1: i'll try and kick off a local build to rule out something funky going on though, good to know it's working on the build bot at least
[05:27:53] Beirdo: yeah, you may want to go to the build box and rm -rf external/ under mythtv
[05:28:00] Beirdo: and let git pull it clean
[05:28:58] sphery (sphery!~mdean@mythtv/developer/sphery) has quit (Ping timeout: 246 seconds)
[05:39:17] MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv
[05:41:34] XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 240 seconds)
[05:50:41] sphery (sphery!~mdean@mythtv/developer/sphery) has joined #mythtv
[06:03:34] MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 240 seconds)
[06:05:35] MaverickTech (MaverickTech!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv
[06:09:24] superm1: Beirdo, well same thing happened in a local fresh c/o and build in a chroot. i'll do it with an interactive one to further investigate. seems like it might be getting the wrong version.h resolved while building
[06:26:37] superm1: Beirdo, okay, so it looks like it's caused by version.sh in the FFMpeg directory
[06:26:53] superm1: it's creating a version.h in mythtv/external/FFmpeg/version.h
[06:27:37] superm1: it's only happening in my automated builds because a VERSION file is placed in the root of the build directory while building to make sure mythtv --version output matches what is expected
[06:29:14] superm1: here's what the contents of that verison.h end up looking like (which matches what it fetches from VERSION when parsing )http://paste.ubuntu.com/598595/
[06:29:41] Beirdo: pretty sure that version.sh is from ffmpeg
[06:30:25] superm1: from the looks of it, there is a mythtv one and an ffmpeg one both
[06:30:31] Beirdo: yup
[06:30:57] Beirdo: the one in ffmpeg is for the ffmpeg version
[06:31:10] superm1: but they're both keying off the same file to determine that (VERSION)
[06:32:02] Beirdo: in different directories
[06:32:22] Beirdo: they shouldn't be affecting each other
[06:33:17] superm1: version.sh in FFmpeg does a cd "$1" and then cats, so $1 must be pointing to the initial build directory before it steps a few levels in?
[06:34:14] Beirdo: ahhh
[06:34:16] Beirdo: crap
[06:34:24] Beirdo: yeah, it is trying to use VERSION
[06:34:26] superm1: yeah it's first argument according to the Makefile in FFmpeg is SRC_PATH which config.mak points to the root
[06:34:48] Beirdo: however, really, you shouldn't be using that, it's meant to be only for releases
[06:35:24] superm1: it's so that when people report bugs with our packages they have the correct output you expect when running --version
[06:35:46] Beirdo: ummm, what we expect is what you get with no VERSION file :)
[06:35:50] superm1: because we dont have git metadata available at binary package build time that file is generated when the source package is built
[06:36:14] Beirdo: OK, well that's an odd choice to make, but fair enough
[06:36:15] superm1: so without it, it would be a friendly UNKNOWN
[06:36:18] Beirdo: yeah
[06:36:35] Beirdo: OK, I'll have to see how to fix this
[06:37:00] Beirdo: I think it will be not too bad, a small tweak to the ffmpeg makefile
[06:37:09] superm1: if you want to rename the mythtv's version.sh to check for a different file name, that's probably easiest so you dont have to maintain such tweak
[06:37:17] superm1: have it look for something like MYTHVERSION or something
[06:39:25] Beirdo: could do that too, but we already have to tweak ffmpeg's makefile anyways
[06:39:58] Beirdo: adding in the mythffmpeg, et al builds
[06:42:03] superm1: ok, well whatever is best for yall. i'll adjust the packaging scripts if you end up renaming it
[06:42:23] Beirdo: gimme a sec
[06:43:57] Beirdo: try putting in: http://www.beirdo.ca/~gjhurlbu/test/ffmpeg.patch
[06:44:33] Beirdo: errr .diff
[06:44:36] Beirdo: sorry
[06:45:44] superm1: yup that appears to fix it. version.h is generated with "#define FFMPEG_VERSION "UNKNOWN"" which looks correct to me
[06:46:23] Beirdo: cool, you should be safe with VERSION then. I'll check that in
[06:47:25] superm1: great, thanks!
[06:49:24] Beirdo: no prob
[06:50:25] pheld (pheld!~heldal@cl-5.osl-01.no.sixxs.net) has joined #mythtv
[07:12:59] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv
[08:02:41] jya: jpabq: Sorry, pasted the wrong one: http://pastebin.com/4G5uGnjm
[08:07:56] stoffel (stoffel!~quassel@p57B4A903.dip.t-dialin.net) has joined #mythtv
[09:17:19] frankbean (frankbean!~frankbean@173.234.32.27) has joined #mythtv
[09:49:42] frankbean (frankbean!~frankbean@173.234.32.27) has quit (Quit: Textual IRC Client: http://www.textualapp.com/)
[10:04:31] NightMonkey (NightMonkey!debian-tor@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!)
[10:05:03] mike|2 (mike|2!~mike@c-24-21-63-118.hsd1.or.comcast.net) has quit (Remote host closed the connection)
[10:05:53] mike|2 (mike|2!~mike@c-24-21-63-118.hsd1.or.comcast.net) has joined #mythtv
[10:19:07] gigem (gigem!~gigem@mythtv/developer/gigem) has joined #mythtv
[10:43:26] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[10:48:37] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[10:48:51] okolsi (okolsi!~mythtv@a88-115-42-16.elisa-laajakaista.fi) has quit (Read error: Operation timed out)
[10:51:27] okolsi (okolsi!~mythtv@a88-115-42-16.elisa-laajakaista.fi) has joined #mythtv
[10:59:45] stoffel (stoffel!~quassel@p57B4A903.dip.t-dialin.net) has quit (Ping timeout: 250 seconds)
[11:14:38] andreax (andreax!~andreaz@p57B945D0.dip.t-dialin.net) has quit (Read error: Connection reset by peer)
[11:52:08] davide_ (davide_!~david@mythtv/developer/gigem) has quit (Remote host closed the connection)
[11:52:37] davide_ (davide_!~david@mythtv/developer/gigem) has joined #mythtv
[12:07:10] dblain: Captain_Murdoch: The only concern I have with your patch is as follows: My redesign of the httpServer which hasn't been committed yet would make the response buffer inaccessible. This would be required to support chunk-encoding ( where the response is sent in multple small parts).
[12:08:16] dblain: With that said, I have no better option for supporting translations, so I would say commit the patch and I'll figure a way to merge in my changes.
[12:09:34] dblain: iamlindoro: Escaping json reponses is definitely needed (an oversight on my part). I'll see what I can do to add it over the next few days.
[12:21:35] jarle (jarle!~jarle@70.84-234-133.customer.lyse.net) has joined #mythtv
[12:55:55] Captain_Murdoch: dblain, it has to be accessible somewhere though, so we can always move the translate code. When testing with .qsp, I originally had HTTPRequest::SendResponse() call a HTTPRequest::TranslateResponse(), but since .html files are ResponseTypeFile, I had to move the code somewhere else or try to handle things with a different code base in SendResponseFile(). slurping in the .html and .js seemed the easiest way to be able to re-use
[12:55:56] Captain_Murdoch: the translation substitution code.
[13:09:30] Jordack (Jordack!~jordack@h69-131-44-221.mdsnwi.tisp.static.tds.net) has joined #mythtv
[13:13:33] dblain: what about only allowing translations to happen on .qjs and .qsp files. I like to make it obvious what files are modified by the server and which ones are left untouched.
[13:13:52] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[13:16:04] dblain: Captain_Murdoch: it should be easy enough to merge your translation logic/syntax into the Scripting::EvaluatePage method.
[13:16:18] dblain: That way we are only processing the text once.
[13:21:42] dekarl (dekarl!~dekarl@e180143043.adsl.alicedsl.de) has quit (Ping timeout: 240 seconds)
[13:52:49] Goga777 (Goga777!~Goga777@shpd-92-101-138-196.vologda.ru) has joined #mythtv
[14:00:07] Captain_Murdoch: dblain, I didn't think we'd want to rename all .html/.js files into .qsp/.qjs just to translate since there's a performance hit on .qsp/.qjs since they are processed line by line. if you don't think that's an issue then I'm fine with that. iamlindoro and I discussed something similar.
[14:00:10] ** Captain_Murdoch is afk for a while. **
[14:02:21] j-rod|afk is now known as j-rod
[14:05:36] stoffel (stoffel!~quassel@p57B4A903.dip.t-dialin.net) has joined #mythtv
[14:13:51] kurre (kurre!~tomimo@xdsl-83-150-88-111.nebulazone.fi) has quit (Ping timeout: 248 seconds)
[14:13:57] kurre (kurre!~tomimo@xdsl-83-150-88-111.nebulazone.fi) has joined #mythtv
[14:14:38] tomimo (tomimo!~kurre@xdsl-83-150-88-111.nebulazone.fi) has quit (Ping timeout: 260 seconds)
[14:16:33] tomimo (tomimo!~kurre@83.150.88.111) has joined #mythtv
[14:28:31] Goga777 (Goga777!~Goga777@shpd-92-101-138-196.vologda.ru) has quit (Remote host closed the connection)
[14:48:23] MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv
[14:51:29] MaverickTech (MaverickTech!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 276 seconds)
[14:55:44] dblain: Captain_Murdoch: It's hard to tell which would be more of a performance problem. The .qsp approach reads each line and generates Qt Script that ultimately renders the page, while your translate function calls replace multiple times which iterates through the string and realloc's/memcpy's the data numerous times per replace call. Ultimately I think your translate call would perform marginally
[14:55:44] dblain: faster.
[14:58:41] dblain: My issue is more from a ideological point of view. When I see an html or js file, I expect it to be sent to the client without any modification. Ultimately, I can live with it either way, that is why I suggested you just commit the change.
[15:00:57] XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv
[15:03:18] MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 240 seconds)
[15:03:38] dblain: Quick question... does the <?text?> break any html tools that might be used by people? It would be nice if the text used to indicate a string to be translated be transparent to any tools / browsers that may be used to view/edit the html/js outside mythbackend.
[15:04:33] iamlindoro: Could always use a more conventional HTML syntax if that's a concern
[15:04:40] iamlindoro: <tr string="blah blah" />
[15:05:24] iamlindoro: Though of course that means escaping the quoted string, but not the end of the world
[15:06:01] dblain: that wouldn't display the text, but something like <tran>blah blah</tran> may be better. (<tr> is already used by tables)
[15:06:30] iamlindoro: Since it's being parsed server side, the client would never see the <tr>
[15:06:32] dblain: I think most tools/browsers will ignore a tag they don't understand
[15:06:35] iamlindoro: or whatever <trans>
[15:06:50] dblain: when it's served up by the backend, that is true.
[15:07:22] dblain: I'm thinking while being developed someone might want to use a tool like dream weaver, expressions web, etc...
[15:07:24] iamlindoro: It may be a moot point, though, I suspect <? ?> is as safe as <% %>, minimally
[15:07:48] dblain: true, most tools do understand script tags.
[15:08:11] dblain: <? is used by php, right?
[15:08:26] iamlindoro: the problem with dreamweaver and others from recent experience with playing with them on the HTML setup stuff is that they hork the heck out of all the HTML to make things "dreamweavery"
[15:08:42] iamlindoro: Yeah, I think you're right
[15:09:19] dblain: I only bring this up so we can make sure to stay "standards compliant" as much as possible.
[15:10:25] iamlindoro: could use <| |> perhaps? That ones probably not in use
[15:11:19] ringo_ (ringo_!18e9b715@gateway/web/freenode/ip.24.233.183.21) has joined #mythtv
[15:11:30] ringo_: does the latest mythtv support both version of the crystalhd decoder (models 12 and 15)?
[15:11:37] dblain: Actually, I was thinking the tools wouldn't have as much of a problem with <? because it is used!  :) not that we shouldn't use it.
[15:11:41] iamlindoro: ringo_: wrong channel, see topic
[15:12:05] wagnerrp: ringo_: you were in the correct place the first time you asked
[15:12:33] ringo_: I figured the users might not know because it is not in the documentation
[15:12:45] iamlindoro: This isn't "meet the devs"
[15:12:48] iamlindoro: It's "be a dev"
[15:16:13] iamlindoro: dblain: By that same topic I wonder if "smart" tools that try to do something with the php tags might get confused by our use of those reserved ones
[15:16:17] iamlindoro: er same token
[15:16:33] dblain: true.
[15:16:45] ringo_: I am a developer and have contributed to the VLC and ffmpeg projects. I am currently testing their latest implementation of the crystalhd decoder support and neither of them support the old model (12). ffmpeg supports hardware descaling but vlc does not. I was also wondering if mythtv has hardware descaling support. Lasty, there is a debate on wether hardware deinterlacing is possible using the device but I was hoping to chat with som
[15:17:04] iamlindoro: ringo_: You have an answer in the correct channel
[15:18:24] iamlindoro: and again, this channel is for discussion about development on mythtv being done by the people doing the talking-- it's not enough to be a dev, you need to be discussing topic related to your own personal development of MythTV
[15:18:55] ringo_: ok, I got it now ... only talks about code being written !!!
[15:19:17] iamlindoro: exactly right
[15:19:43] MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv
[15:22:18] XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 260 seconds)
[15:24:48] ringo_ (ringo_!18e9b715@gateway/web/freenode/ip.24.233.183.21) has quit (Quit: Page closed)
[15:26:23] jarle (jarle!~jarle@70.84-234-133.customer.lyse.net) has quit (Remote host closed the connection)
[15:28:09] jarle (jarle!~jarle@70.84-234-133.customer.lyse.net) has joined #mythtv
[15:30:44] iamlindoro: dblain: I think we're probably damned if we do and damned if we don't... It "feels" like maybe using an unreserved tag is probably the safer way to go, but I'll leave it to you and Captain_Murdoch to decide what you want, I'm ahppy either way
[15:50:29] abqjp (abqjp!~abqjp@97-119-174-22.albq.qwest.net) has joined #mythtv
[16:02:05] Captain_Murdoch: dblain, iamlindoro, <tran>Translatable Text</tran> sounds OK to me, and it will show up as just 'Translatable Text' on a browser if viewed directly that way. if we're only going to translate .qsp and .qjs files, then I can move the translation call into ServerSideScripting::CreateMethodFromFile() as well and since that operates on a QString line by line it makes things easier than all the copying to/from QByteArray I had to do w
[16:02:05] Captain_Murdoch: ith the other method.
[16:02:49] kwmonroe (kwmonroe!~kwmonroe@32.97.110.58) has joined #mythtv
[16:06:34] iamlindoro: Captain_Murdoch: sure, works for me. I do have some mild concerns about how we'll handle "flat" HTML and js, but I suppose it will work out in the end
[16:07:34] iamlindoro: In a worst case scenario we can always just convert everything to qsp/qjs
[16:07:44] Captain_Murdoch: the idea is to just rename all .html and .js that need translations to .qsp and .qjs.
[16:07:49] Captain_Murdoch: there's no converting, just rename.
[16:08:02] dblain: Captain_Murdoch: I'll leave the final decision up to you. Looking over the code, I think your current translate approach would perform a little better than using the script engine. So, I've stated my opinion... do what you think is best.
[16:09:02] ** dblain also debated in his mind how much does the performace difference matter when all it's used for is a browser based setup! **
[16:10:01] Captain_Murdoch: dblain, yeah I thought similar. eventually parts of mythweb might be better done in backend .qsp/.qjs though.
[16:10:26] Captain_Murdoch: even if mythweb just proxied the data like it does with the status page.
[16:11:30] dblain: true. It's a constant battle for me... best design or best performance. most of the time you can achieve both, but some times it's hard to stike a balance.
[16:11:33] Captain_Murdoch: I like the idea of being able to operate on the full buffer and not having to translate line by line and for our .html/.js/.qsp/.qjs files, I don't see chunking as a necessity.
[16:12:52] Captain_Murdoch: iamlindoro, are you fine with .qsp/.qjs being the only translatable files? ie, .html and .js are static, passed through un-modified.
[16:12:55] dblain: regarding chunk-encoding. I wanted to make it transparent to any response. If the response buffer is > than XX size, and http = 1.1 send partial response.
[16:13:40] dblain: (mostly for large datasets returned from the API methods and video/music streaming)
[16:13:52] Captain_Murdoch: dblain, will chunking be done at the delivery later (ie, will a buffer be built first) or will it be handled by some output stream so there is never a full buffer view?
[16:14:00] dblain: I could alway make it optional for html server.
[16:14:51] dblain: ultimately I wanted it to be baked into the output stream handling, so huge files/datasets don't need to be fully buffered.
[16:15:21] dblain: but like I said, I can make it optional for the html server if you need access to the entire buffer.
[16:15:31] Captain_Murdoch: so in that case, translation would have to be done in the stream if we wanted translation to occur there.
[16:15:45] Captain_Murdoch: I'm wondering if we ever want translation anywhere but the html server.
[16:15:57] Captain_Murdoch: since the rest is data which we shouldn't be translating.
[16:16:17] Captain_Murdoch: exluding the status page itself which could be reworked as .qsp probably.
[16:16:21] dblain: I don't think the translation should be any lower in the protocol stack than it currently is.
[16:16:38] tomimo (tomimo!~kurre@83.150.88.111) has quit (Ping timeout: 240 seconds)
[16:17:03] kurre (kurre!~tomimo@xdsl-83-150-88-111.nebulazone.fi) has quit (Ping timeout: 248 seconds)
[16:17:09] dblain: to me the output stream handler is one level up from the transport layer and should not have any "business logic" for lack of a better term, in it.
[16:17:17] Captain_Murdoch: are the .qsp 'scripts' cached in any way?
[16:17:59] Captain_Murdoch: is that what m_mapScripts is?
[16:18:08] dblain: yes. Once accessed, it's cached. It only reprocesses the original file if the file date/time changes.
[16:19:03] ** dblain just realized if someone wanted to crash a machine, they could put a huge qsp file and it would run out of memory! **
[16:19:08] Captain_Murdoch: ok, so I propose translating only .qsp/.qjs and performing the translation inside CreateMethodFromFile() so we only translate once, not every time the .qsp is displayed by htmlserver
[16:19:34] dblain: makes sense.
[16:19:54] Captain_Murdoch: that will also fit with your chunking.
[16:20:32] dblain: yep. but it does require all static html to be .qsp which I thought you didn't like.
[16:20:35] Captain_Murdoch: hmm, does that mean that you'd be caching .html files that we renamed to .qsp only to get translations?
[16:20:46] Captain_Murdoch: yeah. that has me rethinking that.
[16:21:04] dblain: yes. with the current code, it will try and cache all .qsp & qjs files.
[16:21:26] dblain: nothing saying we can't optimise the cache logic.
[16:21:38] Captain_Murdoch: I don't mind static .html being served un-modified, but anything we want to translate woudl be cached. I guess that's not a big deal, the html dir isn't huge.
[16:22:13] Captain_Murdoch: if it gets too large, we could implement LRU or something.
[16:22:19] dblain: I can steal some code from the SSDP cache I created where it purges entries after a given time span.
[16:23:18] dblain: the TaskQueue class is meant for that kind of thing :)
[16:23:22] Captain_Murdoch: I don't see cache size as an issue unless you're caching the resulting HTML of the script once it's run which you can't do since it's DB data dependent.
[16:23:56] Captain_Murdoch: so I think we're OK with saying anything with <tran> must be .qsp or .qjs.
[16:24:01] dblain: It's only caching the original file after being converted into QtScript.
[16:24:16] dblain: okay.
[16:25:50] dblain: Did you want to use the same syntax for client side javascript? something_java_like( "<tran>blahblah</tran>" );
[16:26:15] dblain: seems messy, but then again, consistency is a good thing.
[16:27:07] Captain_Murdoch: so no need to see the full buffer to translate, I'll just translate in ServerSideScripting::CreateMethodFromFile() as the file is read in or I may look at slurping it into a temp buffer to translate then feeding it line by line to processLine().
[16:27:42] Captain_Murdoch: yeah, I think we were going to use the same syntax in .qjs. I haven't tested my current patch with that, but the concept should work.
[16:29:07] Captain_Murdoch: I like the consistency and having one method makes it easy to grep for. we are going to have to have a script to pull out translatable strings and stuff them into a .h file for translating like themes/themestrings.h
[16:29:15] dblain: With a little work, you should be able to add the translate code to ServerSideScripting::ProcessLine. If you want to only parse each line only once.
[16:30:00] Captain_Murdoch: yeah, I thought about adding in processline, but then that means creating/destroing the <tran> regex once per line since QRegExp isn't thread safe.
[16:30:02] dblain: If you would prefer, I can look into doing the merge. I just won't be able to look at it for a couple of days.
[16:30:42] Captain_Murdoch: I'd rather create the QRegExp once outside the while loop since creating the regex is an expensive operation.
[16:31:13] dblain: Create it outside the loop and pass it as a parameter into the processline method?
[16:31:31] Captain_Murdoch: if that's OK with you, I'm fine with that.
[16:32:24] Captain_Murdoch: I wasn't planning on allowing <tran> tags to span lines, so the </tran> must be on the same line.
[16:32:37] dblain: Is the RegExp approach even needed give the way the current code is processing the line. Seem to me we can just look for an additional begin/end marker and handle it in the same loop.
[16:33:00] dblain: ah. I would think we might need it to span lines.
[16:33:27] Captain_Murdoch: I don't think we allow line breaks in c++ strings.
[16:33:59] dblain: Not sure, but in html they are allowed.
[16:34:24] dblain: we can limit to single line for now.
[16:35:04] Captain_Murdoch: :| that makes replacement hairier. I have to build the string without the line break in order to translate it, then where do I put the translated text? also, what if there is no trailing </tran>.
[16:35:46] dblain: No trailing </tran> is an error! I hate how html allows for broken markup. :/
[16:36:15] Captain_Murdoch: yes, it's an error, I agree, and would end up with a broken page.
[16:37:10] Captain_Murdoch: main issue is the 'how to translate multi-line text'. processLine would have to strip off everything starting with <tran> and then X lines later it would stuff in the translation when it finally found a </tran>
[16:38:11] Captain_Murdoch: not impossible, but much more complicated than operating on a buffer where the .replace() call can replace the same translated string multiple times in one call.
[16:38:59] knightr: Captain_Murdoch, themestrings already deals with it, I would suggest dealing with it similarly...
[16:39:27] knightr: (\\n in text and removal of unessential spaces if IIRC...)
[16:40:03] Captain_Murdoch: knightr, not really an issue with getting things into the .h file. issue is translating on the fly in the backend webserver since I have to find the string to translate and then call tr() on it.
[16:40:46] knightr: from memory they are cleaned on the fly for the ThemeUI strings...
[16:41:25] knightr: there's some overhead from doing it but I'm not sure how we could deal with it in a way that does cause it...
[16:41:30] tomimo (tomimo!~kurre@xdsl-83-150-88-111.nebulazone.fi) has joined #mythtv
[16:41:34] knightr: s/does/doesn't
[16:41:36] cdev (cdev!~androirc@190.sub-75-251-119.myvzw.com) has joined #mythtv
[16:41:50] cdev: cap
[16:43:00] cdev: this I'd dblain... my work PC rebooted. will be back in approximately 20 min.
[16:43:46] Captain_Murdoch: knightr, themestring tool actually parses the xml so it already has the text in a QString that it can easily perform .replace() calls on to strip out line feeds, escape quotes, etc.. the html server code is processing lines of a file, it doesn't have a nice XML Dom to look at.
[16:44:48] cdev (cdev!~androirc@190.sub-75-251-119.myvzw.com) has quit (Client Quit)
[16:44:53] Captain_Murdoch: and the html server code is reading a line at a time, so I'm just saying it would have to be a state machine with a buffer for the untranslated text, then once we find the </tran> tag a few lines later, we look in that buffer and translate it and write out the translated text.
[16:45:12] kurre (kurre!~tomimo@xdsl-83-150-88-111.nebulazone.fi) has joined #mythtv
[16:45:54] knightr: Captain_Murdoch, ah ok... thought it was already loaded in memory, you're talking of what happens before that, sorry...
[16:46:34] Captain_Murdoch: yeah, talking about translating as it is loaded. the html server doesn't parse html, it just parses the server side scripting and passes everything else through directly.
[16:48:28] Captain_Murdoch: we'd have a html/htmlstrings.h file or something similar to the themes/themestrings.h file. that would be populated by something like the themestrings tool, but probably written in something like perl since it needs to work for html and javascript files and it just looking for text between <tran> and </tran> tags.
[16:48:37] knightr: ok...
[16:48:41] Goga777 (Goga777!~Goga777@shpd-92-101-138-196.vologda.ru) has joined #mythtv
[16:50:09] Captain_Murdoch: I have a proof of concept patch working, and can display translated strings on the backend setup webpages, but we were discussing a better way to implement the server side portion and what file extensions we'd process for translatable strings.
[16:50:10] davide_ (davide_!~david@mythtv/developer/gigem) has quit (Remote host closed the connection)
[16:50:39] davide_ (davide_!~david@host103.16.intrusion.com) has joined #mythtv
[16:50:39] davide_ (davide_!~david@host103.16.intrusion.com) has quit (Changing host)
[16:50:39] davide_ (davide_!~david@mythtv/developer/gigem) has joined #mythtv
[16:50:58] tris (tris!~tristan@173-164-188-122-SFBA.hfc.comcastbusiness.net) has quit (Excess Flood)
[16:52:35] knightr: ok, I see you used the dynamic ones (qsp and qjs?) for that since that's what will be interpreted by the server (and not only served like html...)
[16:53:01] knightr: how will you deal with drop downs, same principle?
[16:55:03] tris (tris!~tristan@173-164-188-122-SFBA.hfc.comcastbusiness.net) has joined #mythtv
[16:56:01] Captain_Murdoch: yeah, anything that needs to be translated will be wrapped like this: <tran>Translatable Text</tran> 'Translatable Text' would get translated and the tags removed.
[16:56:06] dblain: Captain_Murdoch: If you want, we can limit to a single line for now, and can look into extending it to multi-line if we find there is a large enough need.
[16:56:08] Goga777 (Goga777!~Goga777@shpd-92-101-138-196.vologda.ru) has quit (Remote host closed the connection)
[16:56:37] knightr: ok, thanks!
[16:56:38] Captain_Murdoch: dblain, I'll take a look at multi-line, it's not that hard. and I don't think I need those QRegExp if I use QString::trimmed().
[16:57:40] Captain_Murdoch: knightr, so the raw .qsp could contain <option><tran>Option #1 Text</tran></option><option><tran>Option #2 Text</tran></option> etc..
[16:58:06] Captain_Murdoch: the web browser would see <option>Option #1 Text</option><option>Option #2 Text</option> for English users.
[16:58:25] Captain_Murdoch: en_US users. :)
[16:59:24] Goga777 (Goga777!~Goga777@shpd-92-101-138-196.vologda.ru) has joined #mythtv
[16:59:29] knightr: Captain_Murdoch, yep, that's what I understood... (not an HTML guru but I do have to do some once in a while, same principle as a JSP essentially...
[17:00:34] dblain: Captain_Murdoch: Just thought of something. Would there ever be a need to represent the same page in multiple translations?
[17:01:01] Captain_Murdoch: dblain, wouldn't think so. we don't allow mythfrontend to do that.
[17:01:14] Captain_Murdoch: the data itself could be mulitple languages, but that's untranslated.
[17:01:15] dblain: okay... makes life easier!
[17:03:35] dblain: Design by committee never works so take all I've said as just a friendly conversation and feel free to run with the approach you think is best.
[17:04:50] Captain_Murdoch: you've been very helpful, thanks. :) I'm taking what lunch time I have left to look at implementing multi-line translation in ::ProcessLine().
[17:06:58] Malard (Malard!Malard@xbmc/staff/malard) has joined #mythtv
[17:06:59] dblain: for that approach, keep in mind that the rendered QtScript doesn't have to be an exact match to the file. If you want to, you can build the entire multi-line string in memory, and output a single translated QtScript line (in stead of many QtScript lines)
[17:08:15] dblain: you'd just need a place to store the temp string between method calls.
[17:08:30] Captain_Murdoch: yes, was going to do that. if we're in a <tran>, I was going to store the untranslated string, and just not stuff anything of the data after the <tran> onto the sCode textstream. then once we hit the </tran>, I translate the string and stuff it onto the text stream.
[17:09:39] Captain_Murdoch: and I can use my string buffer as the flag to indicate whether I'm in a <tran> currently since .isEmpty() is pretty quick. no need for 2 vars to store the state and the data unless you prefer it that way.
[17:09:58] dblain: sounds good.
[17:10:52] dblain: Also, being html (not sure about js), you can use the normalized string (no need to keep track of extra spaces and such)
[17:11:14] Captain_Murdoch: what's your opinion on allowing only exactly "<tran>" and "</tran>" ie, not "< tran >" or "</ tran>"
[17:11:28] Captain_Murdoch: right, this code would occur after your sLIne = sLine.trimmed();
[17:11:28] dblain: even /r/n could technically be safely removed
[17:12:02] Captain_Murdoch: If appending to my non-empty string buffer, I'll just append a space.
[17:12:03] dblain: I say, make it exact. No need to be too flexible.
[17:12:15] Captain_Murdoch: ok, exact is easy, non-exact means a regex.
[17:12:52] dblain: also, fell free to use any tag you want, I just used <tran> as an example. <tr> would have been nice but is already reserved.
[17:13:00] dblain: err, feel
[17:13:52] Captain_Murdoch: I looked at w3schools.com for other in-use tags and <tran> seems OK to me. could make it <mythtran>, but I don't want to get too wordy since it will be used all over.
[17:14:28] Captain_Murdoch: could use <i18n>
[17:14:51] dblain: agreed. I was thinking shorter :) <t>, or <qtr>, or... I'm sure other will chime in once you decide.
[17:15:47] dblain: <i18n>... hum... not too bad
[17:15:57] Captain_Murdoch: easy enough to change before we get into fixing the html contents. then it's just a perl search and replace.
[17:16:02] dblain: explains what it is... well to developers at least.
[17:16:04] Captain_Murdoch: I'll use <i18n>
[17:16:59] Captain_Murdoch: non-developers wouldn't know <tran> either, so... :)
[17:17:06] dblain: very true!
[17:17:24] Captain_Murdoch: I like i18n, it's easily google-able.
[17:17:29] dblain: I like i18n also.
[17:19:20] dblain: I need to get back to my day job. Let me know if you need help with anything.
[17:21:36] dblain: one last thing... plan on having a os.tr() function available for any server side script.
[17:31:57] Malard (Malard!Malard@xbmc/staff/malard) has quit (Read error: Connection reset by peer)
[17:32:01] Malard|Home (Malard|Home!Malard@78.143.214.202) has joined #mythtv
[17:32:03] Malard|Home (Malard|Home!Malard@78.143.214.202) has quit (Changing host)
[17:32:03] Malard|Home (Malard|Home!Malard@xbmc/staff/malard) has joined #mythtv
[17:32:24] dblain: I take back that last statement... I found native Translation support in QScriptEngine. See for details (I will enble it) http://doc.qt.nokia.com/4.7-snapshot/qscripte . . . torFunctions
[17:44:44] dblain: What's our minimum Qt version, 4.5?
[17:50:40] w0ls0n (w0ls0n!~w0ls0n@rrcs-69-193-75-63.nys.biz.rr.com) has joined #mythtv
[17:51:06] w0ls0n (w0ls0n!~w0ls0n@rrcs-69-193-75-63.nys.biz.rr.com) has left #mythtv ()
[17:52:24] anykey_ (anykey_!~guedel@46-126-247-133.dynamic.hispeed.ch) has quit (Quit: leaving)
[17:53:05] anykey_ (anykey_!~guedel@46-126-247-133.dynamic.hispeed.ch) has joined #mythtv
[17:53:27] NightMonkey (NightMonkey!debian-tor@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[17:56:34] Beirdo: dblain: I believe so. It's in cofigure somewhere
[17:56:39] Beirdo: configure rather
[17:56:53] Captain_Murdoch: dblain, 4.5 yes. so it appears that inside of a <% %> script, we would call var str = qsTr("Translatable Text"); instead of using var str = "<i18n>Translatable Text</i18n>"; although both should do the same. our string puller would have to look for both to build html/htmlstrings.h for translators.
[17:57:22] Captain_Murdoch: 4.5 as of the QNetworkDiskCache in MythDownloadManager.
[17:57:39] Captain_Murdoch: previously 4.4 everywhere but one plugin that needed 4.5 I think.
[17:58:13] dblain: Beirdo, Captain_Murdoch: thanks, 4.5 is what I thought ... the qsTr() is only in 4.5+
[17:58:45] dblain: Captain_Murdoch: yes, both <i18n> & qsTr() would work.
[17:59:09] Beirdo: so many times I've wished it could be 4.7, but there are a whole lot of old distros in use, and it wouldn't gain us much
[17:59:39] anykey_ (anykey_!~guedel@46-126-247-133.dynamic.hispeed.ch) has quit (Ping timeout: 250 seconds)
[18:00:27] dblain: That's why I asked... I'm using 4.7 and sometimes forget to check to see if it would still compiles with the min Qt version.
[18:01:05] dblain: Captain_Murdoch: is having the string puller look for both an issue?
[18:01:26] anykey_ (anykey_!~guedel@46-126-247-133.dynamic.hispeed.ch) has joined #mythtv
[18:01:41] Captain_Murdoch: nah, I imagine we'll use perl or something, so it should be simple.
[18:01:53] dblain: The alternative is having the html use <%= qsTr("Translatable Text") %>
[18:01:55] Captain_Murdoch: just making a mental note really. :)
[18:02:11] dblain: That would require no ne coding for translation support.
[18:02:16] dblain: new
[18:04:04] stoffel (stoffel!~quassel@p57B4A903.dip.t-dialin.net) has quit (Remote host closed the connection)
[18:05:02] dblain: I just committed the change that enables the qsTr function so you can give it a try.
[18:05:13] Captain_Murdoch: I think I prefer the <i18n> tag for normal html and 'code' generated by the backend like the generic settings inputs drawn via mythbackend/mythsettings.cpp. iamlindoro, when you get around, what do you think?
[18:05:21] Captain_Murdoch: dblain, ok, thanks.
[18:06:10] dblain: Captain_Murdoch: thanks okay with me also, just wanted make you aware of that option
[18:06:59] Captain_Murdoch: thanks.
[18:07:40] ** dblain is having a very bad typing day... lots of mistakes :( **
[18:09:21] dblain: iamlindoro: I have a patch I think will fix the json encoding issue, but I don't have any data that causes it to fail without the patch. Did you want to test it or should I mess with my database to create some bad data?
[18:11:29] Chutt_ (Chutt_!~ijr@cpe-24-29-225-191.neo.res.rr.com) has quit (Read error: Connection reset by peer)
[18:11:46] Chutt_ (Chutt_!~ijr@24.29.225.191) has joined #mythtv
[18:17:26] dblain: In case someone has time to test it: http://pastebin.com/7xxBMz9h If not, I'll mock up some bad data when I get home tonight.
[18:19:09] pndnass (pndnass!~pndnass@12.40.193.75) has joined #mythtv
[18:20:30] j-rod: finally deployed my hdpvr into my production setup on friday afternoon, for the first time in ages
[18:20:59] j-rod: 20+ hours of recordings on it over the weekend, plus live tv abuse
[18:21:02] j-rod: rock-solid
[18:21:11] j-rod: and this is a first-gen hdpvr
[18:21:20] j-rod: wtf is everyone else doing to make them hang up? :)
[18:21:40] Beirdo: mine's been given to occasional screwups and it hasn't been touched other than for power cycles forever
[18:22:03] j-rod: (now, granted… I'm not using the IR part on it… )
[18:22:20] Beirdo: neither am I. electrical tape over the receiver
[18:22:43] j-rod: meh. just don't load the IR driver. :)
[18:23:03] j-rod: (I'm using firewire for channel-change)
[18:23:19] Beirdo: I didn't have any issues for months, but in the last month or so, it's been eating itself at the worst possible times
[18:23:41] j-rod: yeah, will have to see how mine holds up
[18:24:18] j-rod: but ~7 hours straight, no problem (back to back playoff hockey games)
[18:24:31] Beirdo: nice :)
[18:24:58] Beirdo: just gotta find out the dimensions on that power plug. wish I had a micrometer myself
[18:25:03] j-rod: of course, also, who knows what vintage firmware and/or driver people are running…
[18:25:22] Beirdo: 0x15 I think on mine... or was it 0x12? :)
[18:25:24] j-rod: doesn't say anywhere on their product spec page, or on the power adapter?
[18:25:38] Beirdo: hmm, I should check the spec page
[18:25:53] j-rod: hdpvr 1–3:1.0: firmware version 0x15 dated Jun 17 2010 09:26:53
[18:25:59] Beirdo: the power adapter itself is buried behind the entertainment unit
[18:26:14] j-rod: rhel6.1 kernel
[18:26:22] Beirdo: nice
[18:27:15] XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv
[18:27:31] Beirdo: hmmm, spec page says 5V @ 2A, but not the size of the connetor (not many people will care)
[18:28:06] j-rod: true
[18:29:33] Beirdo: bah, I'll buy a flippin micrometer. A good thing to have in the toolset anyways
[18:29:38] MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 240 seconds)
[18:32:50] danielk22: Beirdo: Most 5V @ 2A transformers will not work with the hd-pvr. I'd go with a 3A or better if doing 3rd party...
[18:33:30] Beirdo: my plan is to plug the wall wart into the board, and then run a matching cable from the board, and have a relay on there to disconnect power
[18:33:58] kwmonroe (kwmonroe!~kwmonroe@32.97.110.58) has quit (Ping timeout: 240 seconds)
[18:34:03] Beirdo: but yeah, overspecing a transformer's usually the best bet if replacing them
[18:34:16] Beirdo: I don't really want to resort to cutting the power cord
[18:35:47] Beirdo: OK, micrometer ordered :)
[18:36:57] Beirdo: so, looking at the latest AutoExpire/Scheduler deadlock we have reported, it matches markk's comments from #9704
[18:37:12] Beirdo: I hope to track that down a bit tonight
[18:37:55] j-rod: hm. anyone know stuff about udev?
[18:38:11] j-rod: bah. nm. not really the right place.
[18:40:39] Beirdo: main thread (or another like the socket thread) is blocked on the scheduler lock, the scheduler is blocked on the autoexpire lock and the autoexpire thread is off waiting for a timeout (seems to be what's happening)
[18:45:38] danielk22: Beirdo: the only lock in autoexpire is the instance lock and it is released in AutoExpire::Sleep() on line 350 (the line we're in in the backtrace)...
[18:46:11] Beirdo: yeah
[18:46:21] Beirdo: and it's released in a couple other places too
[18:46:23] Beirdo: so I
[18:46:34] Beirdo: I'm not sure why it would get deadlocked
[18:47:02] Beirdo: but that seems to be the interaction in the backtrace. It's always fun digging into those
[18:47:31] danielk22: Scheduler... there are two scheduler calls going on.. maybe there is a locking order violation there..
[18:47:47] Beirdo: quite possible
[18:47:59] danielk22: Actually more than two..
[18:48:44] Beirdo: as it seems to only happen when a slave is introduced, it's highly likely that there's a locking messup in scheduling, and the autoexpire is an innocent bystander
[18:49:03] Beirdo: but... we shall see, I guess
[18:49:39] Beirdo: threaded software is always fun stuff to debug. I've had coworkers before that lost hair from it ;)
[18:49:47] wagnerrp: Beirdo: why not integrate the power into the board, and give it a proper NEMA plug?
[18:50:05] Beirdo: wagnerrp: that's another idea I'm toying with :)
[18:50:30] ** wagnerrp hates 'wall warts' **
[18:51:04] Beirdo: I'd rather deal with 5V @ 2A than 110/220VAC, but that is a valid way to do it
[18:51:44] Beirdo: either way would have the desired effect
[18:52:09] Beirdo: the nice thing with using NEMA plug... you can use it for something other thatn the HD-PVR too
[18:52:59] wagnerrp: i was thinking it would still be a DC supply
[18:53:29] wagnerrp: otherwise, you would still be stuck with the HDPVR wall ward
[18:53:32] wagnerrp: wart
[18:53:47] Beirdo: you're going to need that regardless
[18:54:01] Beirdo: I don't really wanna build a 2A power supply :)
[18:54:35] ** wagnerrp puts on his sphery hat **
[18:54:50] andreax (andreax!~andreaz@p57B93B7A.dip.t-dialin.net) has joined #mythtv
[18:54:52] wagnerrp: maybe you could make it a 10A or so, and integrate it with your previous USB blaster design
[18:55:46] Beirdo: heh, I wish my ex-wife would send me the book that I did that design in
[18:56:36] Beirdo: I think I have partial schematics on one of my boxes. Sigh
[19:06:32] Beirdo: with how long it took for her to send my old W-2 that got mailed there... I'll likely never see that book again
[19:18:41] wagnerrp: Beirdo: there we go... seems you need to make it a USB hub as well
[19:19:08] ** wagnerrp wonders how ancient of a machine one must be running that only has four USB ports **
[19:19:34] Beirdo: heh
[19:20:27] Beirdo: and Mark Lord has to give his $0.00001 worth
[19:21:04] Beirdo: as you can get a 4-port hub for what? $5? hardly worth incorporating that in
[19:21:31] Beirdo: sorry. $7
[19:21:53] Goga777 (Goga777!~Goga777@shpd-92-101-138-196.vologda.ru) has quit (Remote host closed the connection)
[19:21:58] Beirdo: http://www.amazon.com/Black-4-Port-High-Speed-USB/dp/B002FFT8Z6/
[19:22:08] Beirdo: or that. $0.22 + 2.98 shipping
[19:22:14] wagnerrp: i dont know how you could run out of usb ports
[19:22:24] Beirdo: by not buying a hub
[19:22:49] Beirdo: my backend box is nearly fully used, but nothing that the 7-port hub sitting next to it can't fix
[19:22:57] wagnerrp: even in the P4/amdxp era, any free space on the board just means the designers had more space for root hubs
[19:23:20] wagnerrp: need more ports? just use another header
[19:23:30] wagnerrp: i think my desktop has like 14 ports available
[19:25:30] wagnerrp: the only real reason to use hubs these days is for convenience, moving ports to an easier location than behind your case
[19:25:55] Beirdo: usually, yeah
[19:26:20] Beirdo: ordered a couple el-cheapos for my supply box anyways
[19:26:33] Beirdo: usually when you need that one extra port it's at 3am :)
[19:27:21] Beirdo: my dev box is nearly full up too... has several USB-FTDI serial cables, etc. And once I design this one, there'd be another while working on it
[19:27:35] Beirdo: it is an old (free) Dell
[19:32:12] Beirdo: anyways, I'll consider doing a wall-wartless edition, but I think doing straight AC is the most versatile setup
[19:32:40] Beirdo: and doing passthru DC the easiest.
[19:52:07] FinnTux (FinnTux!~smr@et456.netikka.fi) has joined #mythtv
[19:52:49] MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv
[19:55:12] XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 240 seconds)
[20:45:36] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[20:53:06] Jordack (Jordack!~jordack@h69-131-44-221.mdsnwi.tisp.static.tds.net) has quit ()
[21:05:50] danielk22: Beirdo: in [75d935] AnalogSignalHandler should not inherit from QObject, instead "public slots" should just be "public".. that's a hangover from long ago when the channel scanner used signal and slots and was extremely prone to crashing on multi-core systems.
[21:10:18] Beirdo: ahhh
[21:10:29] Beirdo: we aren't signalling to them anymore?
[21:10:49] Beirdo: would you like me to take that, or are you on it?
[21:11:51] danielk22: correct.. i'd like it if you took it. i've made the change to mythtv-rec2, but it would take me a while to switch to master and recompile..
[21:12:58] Beirdo: OK, will do, thanks
[21:13:28] Beirdo: fewer oddities, the better :)
[21:21:41] knightr (knightr!~knightr@mythtv/developer/knightr) has quit (Ping timeout: 240 seconds)
[21:22:33] knightr (knightr!~knightr@mythtv/developer/knightr) has joined #mythtv
[21:25:23] Beirdo: compiling now.
[21:30:16] Beirdo: I removed the inheritance completely, it compiles fine
[21:31:47] danielk22: Well it should inherit from that other class... Anyway it would compile even if we were still using the slots.. those only throw runtime errors... but I did grep the code to make sure.
[21:32:19] Beirdo: yes, but not from QObject
[21:32:42] Beirdo: so I took out the public QObject, the Q_OBJECT and the public slots:
[21:32:54] Beirdo: true
[21:33:47] danielk22: right, sounds good
[21:33:53] Beirdo: just doing a full compile before pushing that and the minor changes the user found that fixed the deadlock, apparenly. Uninitialized update_thread in the AutoExpire ctor
[21:34:20] Beirdo: as later, we check if it's NULL... we should have initialized to NULL. Ooops.
[21:34:44] Beirdo: if that's all that the problem was, I'll be quite happy, actually
[21:35:03] danielk22: Oops, both of us missed that! I'm looking at mhi.{cpp,h} now, looks like there is some ickiness left over from the Qt4 port..
[21:35:28] danielk22: Do you have MHI test samples now?
[21:35:28] Beirdo: that wouldn't surprise me
[21:35:32] Beirdo: I have one
[21:35:51] Beirdo: it's very short, but was enough to show the ffmpeg not choking on it now
[21:36:08] Beirdo: may not be long enough to test the usefulness of MHI itself
[21:41:07] thopiekar (thopiekar!~quassel@p4FCD6C74.dip.t-dialin.net) has joined #mythtv
[21:46:37] j-rod is now known as j-rod|afk
[21:47:35] dblain (dblain!~dblain@mythtv/developer/dblain) has quit ()
[21:48:02] dblain (dblain!~dblain@c-76-127-227-175.hsd1.ma.comcast.net) has joined #mythtv
[21:48:02] dblain (dblain!~dblain@mythtv/developer/dblain) has joined #mythtv
[21:48:02] dblain (dblain!~dblain@c-76-127-227-175.hsd1.ma.comcast.net) has quit (Changing host)
[21:49:59] dblain (dblain!~dblain@c-76-127-227-175.hsd1.ma.comcast.net) has joined #mythtv
[21:49:59] dblain (dblain!~dblain@mythtv/developer/dblain) has joined #mythtv
[21:49:59] dblain (dblain!~dblain@c-76-127-227-175.hsd1.ma.comcast.net) has quit (Changing host)
[22:10:54] iamlindoro: dblain, that patch appears to fix the issues I saw with my content
[22:11:02] iamlindoro: sorry for the long delay-- have been off the grid most of today
[22:11:18] iamlindoro: Captain_Murdoch, Seems like a good tag choice to me
[22:11:46] dblain: np. I don't normally like to pawn off testing to others, but I didn't have any data that caused the issue. Thanks for testing it.
[22:12:07] iamlindoro: no problem
[22:20:21] davide_: is it reasonable to require v4l2 for building these days to get any v4l support? iow, is it ok to not support the v4l1 only build case? i've been looking at the mythtv-v4l2-fix.2.patch for #9595 and it seems like it would be much simpler to analyze and verify that way. note this is only for configuring ang building, at run-time, v4l1 would still be a fallback just like it currently is.
[22:21:23] iamlindoro: davide_, How old would a system have to be to not have v4l2 support? It seems like stripping out v4l1 support altogether is probably not unreasonable
[22:21:46] wagnerrp: centos people might complain
[22:22:02] iamlindoro: they complain regardless ;)
[22:24:34] davide_: iamlindoro: i believe the system would have to be pretty old, but i'm asking anyway. fwiw, our current code requires v4l2 and v4l1, so this shouldn't really be a big change. the problem is the currently proposed patch appears to let the user configure v4l1 only.
[22:24:41] wagnerrp: seems like v4l2 should exist in the entire 2.6 kernel line
[22:25:29] wagnerrp: it was originally merged in late 2002, in the 2.5 developmental branch
[22:26:48] davide_: that should be long enough, then. since the current code requires it, i'm going to rework the prosed patch to still require it.
[22:29:20] Beirdo: the poor saps who still use 2.4 kernels... heh
[22:29:24] Beirdo: likely all 0 of them
[22:43:11] thopiekar (thopiekar!~quassel@p4FCD6C74.dip.t-dialin.net) has quit (Read error: Connection reset by peer)
[22:45:38] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 246 seconds)
[22:47:46] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[22:53:44] Malard|Home (Malard|Home!Malard@xbmc/staff/malard) has quit (Read error: No route to host)
[22:55:04] Malard (Malard!~Malard@dsl78-143-214-202.in-addr.fast.co.uk) has joined #mythtv
[23:16:58] danielk22: Beirdo: I'm just looking at [361f21] and the way you're handling the formerly detached threads is not correct... Have you since figured out how to do detached threads using QThread?
[23:24:38] Beirdo: one sec.
[23:25:30] Beirdo: yeah. this->deleteLater is not good
[23:25:59] danielk22: I'm thinking a QRunnable + QThreadPool is the natural replacement in this case...
[23:26:14] Beirdo: I agree
[23:26:39] Beirdo: there are a bunch of them that can become QRunnable in the global threadpool
[23:26:56] Beirdo: and those are fine candidates
[23:27:57] Beirdo: for now, on some of those, it was a "delete before launching a new one", and on some, i think I just let them not get deleted
[23:28:09] Beirdo: but for sure the this->deleteLater() didn't work
[23:28:14] danielk22: My concern here is that we may want to be able to terminate run away jobs.. I don't know how that is currenntly handled.
[23:28:20] Beirdo: and they shoudl become QRunnable
[23:28:27] Beirdo: Hmmm
[23:28:41] Beirdo: yeah, that's a very good point
[23:29:17] danielk22: Right, because the deleteLater won't be processed except by the launching thread, and being "detached" threads we aren't waiting for them to exit before the parent launching thread exits...
[23:29:31] Beirdo: I don't think we have it in there to abort them
[23:29:48] Beirdo: well, deleteLater is done by the main thread in the event handler
[23:30:04] danielk22: Captain_Murdoch: ^^^ Is there currently no means for aborting runaway jobs?
[23:30:15] Beirdo: and due to it being... umm. multithreaded... that can preempt immediately and kill the thread before it even exits too
[23:30:54] Beirdo: AFAIK, the way to do it is to kill the eventual process that gets spawned, but I could be missing something. It would be nice to be able to do it under the control of the jobqueue
[23:31:41] Beirdo: we can remove a job from the queue
[23:32:31] Beirdo: I know wagnerrp is reworking the jobqueue anyways, so as long as we (or should I say...I) don't break it in the mean time ...
[23:32:45] Dave123 (Dave123!~dave@cpe-66-66-127-3.rochester.res.rr.com) has quit (Remote host closed the connection)
[23:33:15] Beirdo: there seems to be a map of flags (by jobID) that the job threads can listen to
[23:33:19] danielk22: hmm, but we still wait for it to exit so that we don't have a zombie process.. but I'm assuming that myth_system handles that on exit by re-parenting, right?
[23:34:06] Beirdo: myth_system will take care of that, you can just let it run and never wait for it to return
[23:34:36] Beirdo: it knows what children were spawned, and will reap them all even if nobody is waiting for them
[23:34:51] danielk22: Beirdo: I mean if you are waiting for them, what happens when you exit the application?
[23:35:11] wagnerrp: danielk22: i dont believe there is any current way to terminate detached processes
[23:35:27] wagnerrp: the closest it gets is sending commands to the process through the database
[23:35:28] Beirdo: If you exit, the children become children of init (IIRC)
[23:35:44] wagnerrp: but that relies on the process knowing to read that information, and not being deadlocked
[23:35:50] Beirdo: if you exit the parent that is
[23:36:46] pheld (pheld!~heldal@cl-5.osl-01.no.sixxs.net) has quit (Quit: Leaving.)
[23:37:13] Beirdo: we may want to consider (at some point) killing all remaining children when the application exits, but we'd have to make sure that won't have adverse effects we were not expecting
[23:37:38] ** Beirdo curses cacti. Why won't you do what I say! **
[23:37:47] wagnerrp: i have the jobqueue set up to do just that in my branch
[23:38:01] Beirdo: cool
[23:38:02] wagnerrp: but that relies on mythjobqueue exiting cleanly
[23:38:24] danielk22: Beirdo: that would solve the problem I see sometimes when I restart the backend and end up with too many commflag processes running..
[23:38:39] Beirdo: I'm not sure we'd want that as a default for everything in the apps quite yet, but it's worth considering
[23:38:46] abqjp (abqjp!~abqjp@97-119-174-22.albq.qwest.net) has quit (Quit: abqjp)
[23:38:54] Beirdo: heh, yeah, I've seen that before too.
[23:39:42] danielk22: AFAIK It looks like the previous detached pthreads had their own problems. They rely on the jobqueue still being there when they child process exits.. but it may not be there anymore if the backend has been restarted..
[23:40:14] Beirdo: yeah, that's not too surprising either
[23:41:52] Dave123 (Dave123!~dave@cpe-66-66-127-3.rochester.res.rr.com) has joined #mythtv
[23:43:52] danielk22: wagnerrp: Beirdo: Captain_Murdoch: Ok, I'm not going to try to convert this to a QRunnable.. In order for that not to cause the mythbackend exit to wait for the last commflag and transcode job to finish before exiting we need to first figure out how to handle these long running jobs on exit..
[23:44:22] wagnerrp: danielk22: i was intending to simply terminate them
[23:47:47] danielk22: wagnerrp: ok, but to do that you need to keep track of their pid's which isn't being done currently AFAIK.
[23:48:13] wagnerrp: its done by the new MythSystem class
[23:48:30] wagnerrp: im using that class for management, rather than the myth_system function
[23:49:01] danielk22: ok.. again it sounds like it is premature for me to convert to QRunnable :)
[23:49:10] wagnerrp: actually, the jobqueue was the (at least my) reason for writing the MythSystem class
[23:49:24] Beirdo: Definitely keep a list of the QRunnable candidates
[23:49:35] Beirdo: I saw a few I wanted to convert recently too
[23:51:35] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[23:55:39] pndnass (pndnass!~pndnass@12.40.193.75) has quit ()
[23:56:26] jpabq: jya, http://pastebin.com/epeF4QND

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