Monday, January 30th, 2012, 00:13 UTC | ||
[00:13:41] | aloril (aloril!~aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi) has joined #mythtv | |
[00:25:39] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya) | |
[01:04:28] | Captain_Murdoch: | wagnerrp, wasn't around then, but am now. if you're wondering about the weights, it should be OK to initialize them all to zero I believe, but I haven't looked at that part of code since it was reworked some. |
[01:05:15] | wagnerrp: | Captain_Murdoch: its been initialized to nothing up till now, and hasnt caused any problems |
[01:05:30] | wagnerrp: | which means the disk scheduler sets it to a default value first before it starts tinkering with it |
[01:05:42] | Captain_Murdoch: | yeah, it should all get set somewhere. |
[01:06:02] | wagnerrp: | im just wondering if there is any worth to moving some of that logic into FileSystemInfo itself |
[01:07:26] | Captain_Murdoch: | possible, I'd have to look at the code again, I can't recall what changes have been made since my original scheduler code. I don't think anywhere but the scheduler uses weights. |
[01:07:42] | wagnerrp: | right, not currently |
[01:08:03] | wagnerrp: | but with videos moved over to storage groups, and music and photos on their way |
[01:08:10] | wagnerrp: | would there be use in doing so? |
[01:11:16] | Captain_Murdoch: | right now, when you write a file to the BE, you can't specify a dir, only a SG. it uses the dir in the group with the most free space. unless we're going to let clients begin to specify the dir to write to, then they don't need to know the weight. I think it'd be better to just let the BE handle the decision if we want to intelligently put the file in some dir based on I/O, etc.. the client may need/want to specify a dir to |
[01:11:16] | Captain_Murdoch: | keep related files together, but I think it's best for the BE to determine the dir in most cases. |
[01:16:24] | wagnerrp: | i was actually thinking more in regards to mythmediaserver |
[01:16:41] | wagnerrp: | so that its file server, and the backend's, could share the same methods |
[01:17:00] | Captain_Murdoch: | the MBE is the only one who knows the true usage of any given filesystem/dir at any point in time, so we should really ask the MBE which dir to use next in all cases. |
[01:17:41] | wagnerrp: | the SBE calls the MBE asking where to store its recordings? |
[01:17:59] | Captain_Murdoch: | no exactly, the scheduler tells the SBE where to record the file to. |
[01:18:09] | Captain_Murdoch: | when it starts the recording. the scheduler fills in the path. |
[01:18:32] | wagnerrp: | ah |
[01:18:54] | Captain_Murdoch: | I think it does that about 60 seconds before the recording starts. then it keeps track of what is in use and what will be in use so it can schedule all recordings about to start. |
[01:19:37] | Captain_Murdoch: | when recording liveTV, the SBE asks the MBE where to record at and if it doesn't get a response quickly, it defaults to the dir with the most free space. |
[01:20:17] | Captain_Murdoch: | so a liveTV session could span multiple disks since the destination could change ever channel/program change. |
[01:20:25] | wagnerrp: | thats the GET_NEXT_LIVETV_DIR? |
[01:20:29] | Captain_Murdoch: | yes |
[01:41:08] | jya (jya!~jyavenard@120.148.99.54) has joined #mythtv | |
[01:41:08] | jya (jya!~jyavenard@120.148.99.54) has quit (Changing host) | |
[01:41:08] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
[02:03:33] | gigem: | stuartm: i think i found the problem. pushing the title check down so we can catch programs with the same programid but different titles causes us to check many, many more ids. moving the title check back up should fix the problem at the expense of not handling those rare cases. |
[02:03:44] | gigem: | i'll rework the change tomorrow. |
[02:06:03] | davide_ (davide_!~david@mythtv/developer/gigem) has quit (Remote host closed the connection) | |
[02:06:25] | davide_ (davide_!~david@host70.16.intrusion.com) has joined #mythtv | |
[02:06:25] | davide_ (davide_!~david@host70.16.intrusion.com) has quit (Changing host) | |
[02:06:25] | davide_ (davide_!~david@mythtv/developer/gigem) has joined #mythtv | |
[02:47:41] | beata (beata!beata@108.12.181.220) has quit (Ping timeout: 252 seconds) | |
[03:41:23] | stichnot_ (stichnot_!chatzilla@nat/intel/x-nzijczywbflrzkqz) has joined #mythtv | |
[03:45:05] | stichnot (stichnot!~chatzilla@192.55.54.40) has quit (Ping timeout: 255 seconds) | |
[03:45:20] | stichnot_ is now known as stichnot | |
[04:02:57] | xris: | can't seem to get git-log to work right. updating the rpm packaging script. any idea if settings were moved when mythmusic/globalsettings.cpp was removed, or if they were just deleted? |
[04:09:59] | sphery: | xris: some became "live" settings (moved) and some were deleted – https://github.com/MythTV/mythtv/commit/aaee5d690 + https://github.com/MythTV/mythtv/commit/7731993a7 |
[04:14:13] | xris: | thanks |
[04:14:32] | xris: | the rpm renames the default music dir, so I need to know if I can kill that change, or redirect it |
[04:15:26] | xris: | looks like MusicDirectory stuff just got removed. |
[04:16:03] | Captain_Murdoch: | I think it's moving to Storage Groups. |
[04:17:11] | xris: | that'd be nice |
[04:17:43] | xris: | yeah, looks like the text string moved to mythui. the rest seems to be gone |
[04:18:42] | xris: | looks like --enable-libvisual is gone, too. |
[04:19:31] | xris: | aha. default storage group in mythtv/libs/libmythbase/storagegroup.cpp |
[04:22:40] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
[04:25:42] | xris: | though maybe it doesn't really matter if I change /mnt/store to /var/lib/mythtv |
[04:31:20] | sphery: | xris: Looks like it's still using MusicLocation (see https://github.com/MythTV/mythtv/commit/aaee5d690#L0R98 ). It's just a setting that's handled inside the mythmusic plugin instead of in a separate settings screen. |
[04:31:51] | sphery: | I think stu artm and/or paul-h are working on adding storage group support, but pretty sure it's not done, yet |
[04:32:42] | Captain_Murdoch: | yeah, not done. I think the ability to play via a remote SG just went in, but the rest of hte support isn't there yet (scan, config, etc.) |
[04:46:22] | jpabq_ (jpabq_!~jpabq@mythtv/developer/jpabq) has joined #mythtv | |
[04:49:43] | xris: | sphery: and looks like it's blank by default? |
[04:51:18] | Beirdo: | stuarta: osx taking a dirt nap today? ;) |
[04:52:52] | sphery: | xris: yeah, looks like it... it may be that mythmusic prompts you for the info on first run? |
[04:54:11] | xris: | yeah, that's good enough for me... |
[05:16:21] | xris: | recording all these kids shows makes me wish we had a "split recording" option. :) |
[05:17:03] | Beirdo: | well, necessity is the mother of invention and all... |
[05:17:35] | xris: | heh |
[05:18:00] | xris: | I'd say that "lack of job coming up will really help" but it'll probably be "replacement job will eat up all of my time" |
[05:18:22] | xris: | that and the channel icon stuff, and helping robertk with his attempts to implement SD's own data download format |
[05:18:46] | Beirdo: | yeah, and we have alcor to repopulate too |
[05:18:50] | xris: | that, too |
[05:33:52] | Beirdo: | and another ticket bites the dust |
[06:28:58] | rsiebert__ (rsiebert__!~quassel@g231186039.adsl.alicedsl.de) has quit (Remote host closed the connection) | |
[06:33:17] | MythBuild: | build #2908 of master-linux-64bit is complete: Failure [failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/2908 blamelist: Gavin Hurlbut <ghurlbut@mythtv.org > |
[06:35:05] | MythBuild: | build #1678 of master-linux-ppc is complete: Failure [failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/1678 blamelist: Gavin Hurlbut <ghurlbut@mythtv.org > |
[06:35:48] | iamlindoro: | and two more spring up in its place ;) |
[06:36:17] | Beirdo: | booooo |
[06:36:31] | Beirdo: | OK, let's fix this |
[06:36:39] | cattelan is now known as cattelan_away | |
[06:36:40] | MythBuild: | build #2656 of master-linux-32bit is complete: Failure [failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/2656 blamelist: Gavin Hurlbut <ghurlbut@mythtv.org > |
[06:37:53] | Beirdo: | serves me right |
[06:38:05] | Beirdo: | broke my own dang rule |
[06:38:40] | skd5aner (skd5aner!~skd5aner@cpe-071-071-242-134.carolina.res.rr.com) has quit (Ping timeout: 276 seconds) | |
[06:39:33] | skd5aner (skd5aner!~skd5aner@cpe-071-071-242-134.carolina.res.rr.com) has joined #mythtv | |
[06:50:31] | MythBuild: | build #1432 of master-debian-stable-64bit is complete: Failure [failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/1432 blamelist: Gavin Hurlbut <ghurlbut@mythtv.org > |
[06:50:42] | Beirdo: | still workin on it |
[06:51:04] | Beirdo: | don't expect it to be long |
[06:52:52] | Beirdo: | symbol visibility, basically |
[06:54:22] | Beirdo: | OK, there |
[07:04:21] | MythBuild: | build #2909 of master-linux-64bit is complete: Success [build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/2909 |
[07:11:49] | MythBuild: | build #2657 of master-linux-32bit is complete: Success [build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/2657 |
[07:14:08] | MythBuild: | build #1679 of master-linux-ppc is complete: Success [build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/1679 |
[07:23:33] | MythBuild: | build #1433 of master-debian-stable-64bit is complete: Success [build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/1433 |
[08:02:25] | map7_ (map7_!~map7@ppp118-209-93-114.lns20.mel4.internode.on.net) has joined #mythtv | |
[08:03:34] | Yancho (Yancho!~mpulis@c171-244.i02-3.onvol.net) has joined #mythtv | |
[08:03:34] | Yancho (Yancho!~mpulis@c171-244.i02-3.onvol.net) has quit (Changing host) | |
[08:03:34] | Yancho (Yancho!~mpulis@unaffiliated/yancho) has joined #mythtv | |
[08:39:49] | iamlindoro (iamlindoro!~iamlindor@c-71-202-67-27.hsd1.ca.comcast.net) has quit (Ping timeout: 240 seconds) | |
[08:44:07] | iamlindoro (iamlindoro!~iamlindor@c-71-202-67-27.hsd1.ca.comcast.net) has joined #mythtv | |
[09:03:47] | stuarta: | Beirdo: nah, we had a power blip just as i was going to bed |
[09:04:24] | stuarta: | sigh, the only thing i didn't restart, is the thing that aint working |
[09:04:39] | stuarta: | no osx build slave for 12hrs or so |
[09:04:42] | stuarta: | minimum |
[09:07:32] | stuarta: | technically it's alive, just unable to contact anything since the dsl is down |
[09:15:04] | IMSanchMac (IMSanchMac!~imsancho@CPE-124-179-203-121.lns6.woo.bigpond.net.au) has left #mythtv ("Leaving") | |
[09:26:48] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya) | |
[09:34:19] | nutron|h (nutron|h!~nutron@174.4.11.74) has joined #mythtv | |
[09:34:19] | nutron|h (nutron|h!~nutron@174.4.11.74) has quit (Changing host) | |
[09:34:20] | nutron|h (nutron|h!~nutron@unaffiliated/nutron) has joined #mythtv | |
[09:39:40] | jeff999 (jeff999!~jeff@124-171-111-66.dyn.iinet.net.au) has joined #mythtv | |
[09:55:08] | jeff999 (jeff999!~jeff@124-171-111-66.dyn.iinet.net.au) has quit (Quit: Leaving) | |
[09:55:37] | jeff999 (jeff999!~jeff@124-171-111-66.dyn.iinet.net.au) has joined #mythtv | |
[09:56:29] | jeff999 (jeff999!~jeff@124-171-111-66.dyn.iinet.net.au) has quit (Client Quit) | |
[09:56:43] | jeff999 (jeff999!~jeff@124-171-111-66.dyn.iinet.net.au) has joined #mythtv | |
[09:57:06] | jeff999 (jeff999!~jeff@124-171-111-66.dyn.iinet.net.au) has quit (Client Quit) | |
[09:57:48] | jeff999 (jeff999!~jeff@124-171-111-66.dyn.iinet.net.au) has joined #mythtv | |
[10:12:12] | nutron|h (nutron|h!~nutron@unaffiliated/nutron) has quit (Quit: Whoosie Electroniums) | |
[10:50:13] | jeff999 (jeff999!~jeff@124-171-111-66.dyn.iinet.net.au) has quit (Ping timeout: 276 seconds) | |
[11:05:03] | mike|2 (mike|2!~mike@c-76-115-119-121.hsd1.or.comcast.net) has quit (Remote host closed the connection) | |
[11:05:53] | mike|2 (mike|2!~mike@c-76-115-119-121.hsd1.or.comcast.net) has joined #mythtv | |
[11:12:44] | jeff999 (jeff999!~jeff@124-171-111-66.dyn.iinet.net.au) has joined #mythtv | |
[11:57:05] | sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Quit: Ex-Chat) | |
[12:00:01] | sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv | |
[12:25:11] | ElmerFudd (ElmerFudd!~le@0x5737a682.cpe.ge-0-1-0-1101.hsnqu1.customer.tele.dk) has quit (Ping timeout: 252 seconds) | |
[12:28:30] | stuartm: | Beirdo: I'm not sure if you saw my request the other day, would it be possible to update cppecheck from 1.50 to 1.52? (1.53 is due out mid-Feb but too late for the feature freeze) |
[12:33:25] | stuartm: | btw, can we run scripts via buildbot at certain stages in the build? I'd be interested in stats such as binary sizes, gcc and QT versions |
[12:37:35] | damaltor (damaltor!sbnc@h1889977.stratoserver.net) has quit (Ping timeout: 252 seconds) | |
[12:41:53] | stuartm: | iamlindoro: in reference to the discussion between wagnerrp and al_nz1 earlier today in -users, do you think it's a good idea to automatically run the video scan on entering mythvideo when there are no videos in the db? It seems like a simple but newbie friendly thing to do |
[12:42:40] | damaltor (damaltor!sbnc@h1889977.stratoserver.net) has joined #mythtv | |
[12:43:20] | wagnerrp: | perhaps a popup, "your library is empty, do you wish to scan for content"? |
[12:43:50] | Seeker`: | wagnerrp++ |
[12:44:55] | stuartm: | we could go with a popup first, but since in 99% of cases the answer will be yes and a scan would take less than a second if the video storage group is empty I'm not sure whether it's really necessary |
[12:47:25] | wagnerrp: | id rather not do it automatically, and give the false impression that a similar scan will always be performed when you entre |
[12:47:44] | stuartm: | combine that with sanity checks on the storage group values i.e. disallow / or /home/{user}/ |
[12:48:01] | stuartm: | wagnerrp: well that's a good point |
[12:49:12] | Seeker`: | a dialog to say "in future to add more videos do X" might help |
[12:49:50] | stuartm: | either way, simple change, big benefit to the first time user who often ends up on the mailing list or IRC asking why they can't see their videos |
[12:53:12] | stuartm: | we should do the same for mythmusic |
[12:53:36] | Seeker`: | stuartm: yeah, its a very good idea |
[12:57:24] | wagnerrp: | stuartm: perhaps its a bit late for inclusion in 0.25, but id rather see the scanning option included as part of the storage group setup |
[12:57:51] | wagnerrp: | i.e. you add or change your path definitions, and it has a button to call the scanner in the backend |
[12:59:02] | stuartm: | wagnerrp: there's still use for prompting a scan from the frontend because not everyone will have videos in their storage group from the moment it's setup |
[12:59:43] | stuartm: | they are just as likely to setup the group/directory and then rip a few DVDs into it |
[13:00:44] | stuarta: | stuartm: you can do pretty much anything with the buildslave |
[13:01:15] | wagnerrp: | theres a config file that basically gives a sequence of commands to run |
[13:01:16] | stuartm: | stuarta: cool |
[13:01:37] | wagnerrp: | no reason why you could have a "collect this information and print it to the log" |
[13:02:39] | wagnerrp: | actually, the 'list install' stop already prints out binary sizes |
[13:02:48] | wagnerrp: | just a big 'ls -lr' |
[13:02:58] | stuarta: | that step already exists |
[13:03:02] | stuarta: | in most builds |
[13:03:09] | stuartm: | ooh, missed that |
[13:03:10] | stuarta: | "list install" |
[13:03:24] | wagnerrp: | echo... echo... echo... |
[13:03:31] | wagnerrp: | :) |
[13:03:35] | ** stuarta just noticed that ** | |
[13:03:59] | stuarta: | i seem to have inherited your brain from yesterday |
[13:04:11] | wagnerrp: | no, ive still got it |
[13:04:15] | wagnerrp: | s/stop/step/ |
[13:04:29] | stuarta: | must be contagious :-o |
[13:06:25] | davide_ (davide_!~david@mythtv/developer/gigem) has quit (Remote host closed the connection) | |
[13:06:46] | davide_ (davide_!~david@host70.16.intrusion.com) has joined #mythtv | |
[13:06:46] | davide_ (davide_!~david@host70.16.intrusion.com) has quit (Changing host) | |
[13:06:47] | davide_ (davide_!~david@mythtv/developer/gigem) has joined #mythtv | |
[13:11:12] | stuartm: | so the lib sizes are pretty static, fluctuating by at most a ~100KB over the past two months |
[13:11:42] | wagnerrp: | would that be worth charting out? |
[13:12:25] | stuartm: | wagnerrp: I think it could be interesting, especially if it helps to identify commits which make a big difference one way or the other |
[13:12:29] | stuarta: | should be easy enough to whip up a webservice so the slaves can call it |
[13:13:03] | wagnerrp: | stuarta: probably easier to just generate it statically every couple hours like cppcheck |
[13:13:42] | stuarta: | but it's compiler/linker/os specific |
[13:14:28] | stuartm: | I'm interested in whether there are steps we can take to bring the sizes down to make the constraints of something like the Raspberry Pi less challenging |
[13:14:57] | wagnerrp: | stuarta: im talking about something external, that just polls through the "list install" output through the buildbot API |
[13:15:53] | stuarta: | actually, that info must be either in the DB or in the ondisk pickles |
[13:16:19] | stuarta: | so i should be able to be generated on the server itself |
[13:17:49] | stuartm: | danielk22: there is a list of exclusions we pass to cppcheck telling it not to even scan certain directories e.g. ffmpeg and other third party stuff, would that be more appropriate for dvbdev? |
[13:18:01] | stuarta: | i thought that's where he put it |
[13:19:05] | stuartm: | stuarta: he modified suppressions which are more fine-grained, it still scans those files but just ignores the warnings generated, suppressions are file-level vs directory level |
[13:20:14] | stuartm: | i.e. you can ignore specific lines or warning types but still report other issues in the file instead of skipping checks on it entirely |
[13:21:30] | stuartm: | exlusions/ignores are listed on the command line – https://github.com/MythTV/extras/blob/master/ . . . _cppcheck.sh |
[13:21:48] | ** stuartm goes to remove mythmusic from the list now that it's been ported to mythui ** | |
[13:22:24] | wagnerrp: | stuartm: im guessing only the binaries are of consequence? |
[13:22:34] | wagnerrp: | or would you want theme information too? |
[13:24:35] | stuartm: | only binaries interest me personally, themes are expected to vary in size as images are added/removed and it doesn't have any affect on resource usage (except for disk space) |
[13:27:35] | wagnerrp: | well this doesnt seem right... |
[13:27:58] | wagnerrp: | viewing the html page for a build file list is 26KB, while the text version is 210KB |
[13:28:29] | wagnerrp: | i guess the html version is coming compressed? |
[13:28:47] | stuarta: | must be |
[13:28:59] | stuarta: | the http headers will tell you |
[13:29:56] | wagnerrp: | Content-Encoding: gzip.... yep |
[13:30:06] | stuartm: | wagnerrp: local size, or download was only that big? most servers gzip compress pages but they should be decompressed after downloading |
[13:30:43] | stuartm: | wagnerrp: interesting, it could gzip the text version too but it's clearly not configured to do that atm |
[13:31:52] | wagnerrp: | well this really only needs to be run once, after that it would just be tacking on a couple builds at a time |
[13:32:09] | wagnerrp: | or set up some API for the buildbots to do so themselves |
[13:32:59] | stuarta: | echo! |
[13:33:06] | stuarta: | :) |
[13:33:30] | wagnerrp: | yeah, i was referring to your suggestion |
[13:33:55] | stuarta: | :) |
[13:34:41] | wagnerrp: | just saying parsing all the old data likely going to be half a GB of text, but however it gets set up, that only has to happen once |
[13:46:00] | stuartm: | fwi it's been a long time since I configured an apache instance, but iirc we should be able to add the text mimetype to the list of things which get gzipped compressed |
[13:46:24] | stuarta: | burn apache burn |
[13:47:10] | wagnerrp: | the buildbot is serving this stuff up all internally |
[13:47:28] | wagnerrp: | apache is at most just proxying it |
[13:47:38] | stuarta: | it's all twisted behind the scenes |
[13:47:45] | stuarta: | so most likely configurable |
[14:05:36] | stuartm: | danielk22: I stuck in debugging to trace the cause of the program status update issue and it's suddenly working as it should ... |
[14:07:26] | ** stuarta smells a race condition ** | |
[14:20:24] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
[14:24:12] | stuartm: | hmm, maybe it only occurs for recordings start and ending during playback |
[14:25:38] | danielk22 (danielk22!~danielk@96.57.9.142) has quit (Ping timeout: 272 seconds) | |
[14:26:12] | stuartm: | yeah, that would make sense ... Add events trigger whole list updates and don't update the cached PI |
[14:28:14] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv | |
[14:46:42] | cattelan_away is now known as cattelan | |
[15:10:22] | ElmerFudd (ElmerFudd!~le@0x5737a682.cpe.ge-0-1-0-1101.hsnqu1.customer.tele.dk) has joined #mythtv | |
[15:17:30] | rsiebert (rsiebert!~quassel@e179130255.adsl.alicedsl.de) has joined #mythtv | |
[15:20:37] | rsiebert___ (rsiebert___!~quassel@g231186039.adsl.alicedsl.de) has quit (Ping timeout: 276 seconds) | |
[15:28:59] | Captain_Murdoch: | stuartm, are you going to remove metallurgy from the myththemes repo? I'm wondering what people (and the authors) about moving Childish and Mythbuntu to the MythTV-Themes/Childish and MythTV-Themes/Mythbuntu on github. we can setup groups under there to allow people who want to maintain those to commit. |
[15:32:36] | stuartm: | Captain_Murdoch: yes, I'll remove it, I'd forgotten it was there |
[15:33:15] | Captain_Murdoch: | ok. for some reason I thought you did that when you asked me to remove it from the download site. I just noticed it was still there so I figured I'd check. |
[15:38:25] | sphery: | Captain_Murdoch: I'm all for moving childish and mythbuntu to there... It solves 2 problems--allows us to get authors/maintainers of the theme permissions to push and makes it less likely for users to think they need to install myththemes repo (especially if we have a good README at MythTV-Themes) |
[15:39:22] | Captain_Murdoch: | sphery, thanks, I figured you'd be on board. I'd like to get them out of our repo as well. |
[15:39:25] | sphery: | all that would be left would be finding people to actually be maintainers... :) |
[15:41:59] | stuarta: | hahaha |
[15:42:38] | jpabq_ (jpabq_!~jpabq@mythtv/developer/jpabq) has quit (Ping timeout: 252 seconds) | |
[15:52:09] | kwmonroe (kwmonroe!~kwmonroe@32.97.110.58) has quit (Quit: Coyote finally caught me) | |
[15:55:09] | kwmonroe (kwmonroe!~kwmonroe@32.97.110.58) has joined #mythtv | |
[16:06:37] | sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Ping timeout: 245 seconds) | |
[16:06:38] | stichnot (stichnot!chatzilla@nat/intel/x-nzijczywbflrzkqz) has quit (Ping timeout: 240 seconds) | |
[16:12:06] | kurre2 (kurre2!~tomimo@xdsl-83-150-88-111.nebulazone.fi) has quit (Read error: Connection reset by peer) | |
[16:13:30] | Beirdo: | stuartm: yeah, shouldn't be a problem to change the version of cppcheck. :) I did miss it earlier |
[16:13:59] | tomimo (tomimo!~kurre@xdsl-83-150-88-111.nebulazone.fi) has quit (Ping timeout: 252 seconds) | |
[16:14:08] | Beirdo: | and yah, we can run a script in there, I have one to report the mythtv version, but we can tweak that to add more details, or run another script too |
[16:18:41] | Goga777 (Goga777!~Goga777@128-71-150-153.broadband.corbina.ru) has joined #mythtv | |
[16:21:31] | sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv | |
[16:26:51] | dekarl-too (dekarl-too!51c8c614@gateway/web/freenode/ip.81.200.198.20) has joined #mythtv | |
[16:35:29] | stuartm: | Beirdo: version info for gcc, qt would be useful when a build fails |
[16:36:01] | jcarlos (jcarlos!~quassel@85.137.99.76.dyn.user.ono.com) has quit (Ping timeout: 276 seconds) | |
[16:36:51] | superm1: | sphery: actually once you move those are you just going to drop myththemes all together? They're all that's left right? |
[16:37:47] | sphery: | superm1: yeah, that's all that's left, so, AFAIK, we'd just drop myththemes repo and users would use the Theme Chooser (as they should be doing, anyway--assuming they have Internet access to the MythTV box) |
[16:38:06] | superm1: | sounds good to me |
[16:38:19] | Seeker`: | this ringbuffer code is certainly fun to try to follow |
[16:38:44] | ** stuarta chuckles ** | |
[16:39:42] | dekarl-too: | http://www.mythtv.org/wiki/User:Dekarl/Burndown_DVB <- my DVB notes for the stuarts, is that helpful that way? |
[16:39:55] | stuartm: | Seeker`: that's easy by comparison to some other areas |
[16:40:01] | Beirdo: | stuartm: seems reasonable. We should do that right up front at the beginning, I guess |
[16:42:03] | Seeker`: | stuartm: im getting there. dont have enough logs to be able to work out why a m2ts file isbeung opened with RemoteFile though |
[16:44:04] | stuartm: | I thought we streamed everything via the backend these days |
[16:45:11] | stuartm: | hah! found it, malformed ADD events |
[16:45:18] | Seeker`: | the attachment to #10294 shows what i am trying to work out |
[16:50:08] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit () | |
[16:50:50] | jcarlos (jcarlos!~quassel@85.137.99.76.dyn.user.ono.com) has joined #mythtv | |
[16:51:06] | sphery: | stuartm / Seeker` : we have code that chooses to use a local path, first, if available, for recordings. markk extended that to work for MythVideo (non-recordings) playback, too, specifically because of the performance difference involved when using myth proto for streaming ISOs |
[16:53:54] | Seeker`: | this isnt quite streaming isos though |
[16:55:02] | Seeker`: | it is a series of files, and there is a failure to start reading from the next file once one has finished until buffers are empty enough to produce stuttering |
[16:57:08] | Seeker`: | the performance is fine mid-file, so if i / someone else can work out what causes the 2 second lag it would work perfectly |
[17:02:45] | Beirdo: | OK, off to work I go |
[17:08:27] | jcarlos (jcarlos!~quassel@85.137.99.76.dyn.user.ono.com) has quit (Quit: No Ping reply in 180 seconds.) | |
[17:08:43] | jcarlos (jcarlos!~quassel@85.137.99.76.dyn.user.ono.com) has joined #mythtv | |
[17:15:19] | zombor_ (zombor_!~zombor_@kohana/developer/zombor) has joined #mythtv | |
[17:18:07] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Read error: Operation timed out) | |
[17:20:02] | Seeker`: | could my problem . e caused by the lack of file_eof_mythiowrapper? |
[17:22:35] | zombor_ is now known as zombor | |
[17:25:20] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Read error: Connection reset by peer) | |
[17:25:20] | zombor_ (zombor_!~zombor_@kohana/developer/zombor) has joined #mythtv | |
[17:27:08] | zombor_ is now known as zombor | |
[17:27:11] | jpabq_ (jpabq_!~jpabq@mythtv/developer/jpabq) has joined #mythtv | |
[17:28:20] | stichnot (stichnot!~chatzilla@192.55.55.39) has joined #mythtv | |
[17:32:46] | tomimo (tomimo!~kurre@xdsl-83-150-88-111.nebulazone.fi) has joined #mythtv | |
[17:33:08] | kurre2 (kurre2!~tomimo@xdsl-83-150-88-111.nebulazone.fi) has joined #mythtv | |
[17:35:51] | stuartm: | jpabq: fixed |
[17:55:46] | Goga777 (Goga777!~Goga777@128-71-150-153.broadband.corbina.ru) has quit (Remote host closed the connection) | |
[18:04:28] | davide_ (davide_!~david@mythtv/developer/gigem) has quit (Remote host closed the connection) | |
[18:04:51] | davide_ (davide_!~david@host70.16.intrusion.com) has joined #mythtv | |
[18:04:52] | davide_ (davide_!~david@host70.16.intrusion.com) has quit (Changing host) | |
[18:04:52] | davide_ (davide_!~david@mythtv/developer/gigem) has joined #mythtv | |
[18:10:13] | dekarl-too (dekarl-too!51c8c614@gateway/web/freenode/ip.81.200.198.20) has quit (Quit: Page closed) | |
[18:11:09] | zombor_ (zombor_!~zombor_@kohana/developer/zombor) has joined #mythtv | |
[18:13:14] | wagnerrp: | markk: does RAOP work over ipv6? or does it require v4? |
[18:13:44] | davide_: | stuartm: Is 70ca0bf0 applicable to fixes-0.24? I think I've seen those same issues where things don't get updated in PBB until I exit and re-enter. |
[18:14:08] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Ping timeout: 260 seconds) | |
[18:14:44] | Seeker`: | been doing some digging . in bluray.cpp the code has a check whether the ampunt of data returned is less than the amoumt requested; should something be done with this check to signal that the next file needs to be read from |
[18:14:47] | zombor_ (zombor_!~zombor_@kohana/developer/zombor) has quit (Read error: Connection reset by peer) | |
[18:15:13] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
[18:15:14] | Seeker`: | i cant confirm that is an indicator of the oroblem just yet though |
[18:16:10] | Seeker`: | i mean bluray.c |
[18:26:19] | zombor_ (zombor_!~zombor_@kohana/developer/zombor) has joined #mythtv | |
[18:26:31] | Captain_Murdoch: | stuartm, did you see the idea I mentioned a while back about allowing a theme to specify an initial fallback theme. so you could make for instance Terra-Blue with overridden images but with fallback to Terra before falling back to default-wide. |
[18:27:37] | Captain_Murdoch: | the theme downloader could handle dependencies, so if you install Terra-Blue, it auto-installs Terra as a dependency. |
[18:28:33] | Captain_Murdoch: | from the mythui side, it just inserts a new dir into the searchpath. |
[18:28:53] | joki (joki!~joki@p54864CC5.dip.t-dialin.net) has quit (Ping timeout: 255 seconds) | |
[18:29:00] | joki- (joki-!~joki@p54862623.dip.t-dialin.net) has joined #mythtv | |
[18:29:06] | Captain_Murdoch: | would allow for 'tweaks' to themes. |
[18:29:10] | joki- is now known as joki | |
[18:29:50] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Ping timeout: 252 seconds) | |
[18:32:12] | Beirdo: | MythBuild: force build cppcheck-master now |
[18:32:13] | MythBuild: | build forced [ETA 9m18s] |
[18:32:13] | MythBuild: | I'll give a shout when the build finishes |
[18:34:13] | MythBuild: | Hey! build cppcheck-master #538 is complete: Success [build successful] |
[18:34:13] | MythBuild: | Build details are at http://code.mythtv.org/buildbot/builders/cppc . . . r/builds/538 |
[18:34:50] | Beirdo: | ummm |
[18:35:25] | Beirdo: | stuartm: I think some cppcheck config tweakage will be in order for 1.52 :) |
[18:36:36] | Beirdo: | let me try that without HAVE_RULES=yes |
[18:36:52] | Beirdo: | I don't recall which way it was build last time. One moment |
[18:37:11] | Beirdo: | but 3263 results (up from 179 or so...) |
[18:37:24] | Beirdo: | MythBuild: force build cppcheck-master now |
[18:37:29] | MythBuild: | build forced [ETA 5m39s] |
[18:37:29] | MythBuild: | I'll give a shout when the build finishes |
[18:37:46] | kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has joined #mythtv | |
[18:39:09] | MythBuild: | Hey! build cppcheck-master #539 is complete: Success [build successful] |
[18:39:09] | MythBuild: | Build details are at http://code.mythtv.org/buildbot/builders/cppc . . . r/builds/539 |
[18:39:39] | Beirdo: | no difference |
[18:44:17] | Beirdo: | gonna recompile 1.50 for the moment, don't have much time to mess with it |
[18:45:01] | Beirdo: | MythBuild: force build cppcheck-master now |
[18:45:02] | MythBuild: | build forced [ETA 3m39s] |
[18:45:02] | MythBuild: | I'll give a shout when the build finishes |
[18:45:08] | MythBuild: | build #540 of cppcheck-master is complete: Failure [failed shell shell_1] Build details are at http://code.mythtv.org/buildbot/builders/cppc . . . r/builds/540 |
[18:45:14] | Beirdo: | what? |
[18:45:43] | Beirdo: | OK, we must not have had 1.50 stock |
[18:45:44] | Beirdo: | hmm |
[18:45:52] | zombor_ (zombor_!~zombor_@kohana/developer/zombor) has quit (Read error: Connection reset by peer) | |
[18:46:15] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv | |
[18:46:18] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
[18:46:30] | stuartm: | should have been a simple update :( |
[18:46:40] | Beirdo: | yeah |
[18:46:54] | stuartm: | davide_: yes, it applies to fixes, I will be backporting shortly |
[18:46:59] | Beirdo: | unfortunatley, I shoulda copied aside the previous binary. :) |
[18:47:19] | Beirdo: | luckily, my git pull indicated the previous sha1 |
[18:48:23] | Beirdo: | MythBuild: force build cppcheck-master now |
[18:48:24] | MythBuild: | build forced [ETA 3m39s] |
[18:48:24] | MythBuild: | I'll give a shout when the build finishes |
[18:48:47] | Beirdo: | I'll go back to tweaking it tonight, do you wanna just run the tip of master? |
[18:49:05] | stuartm: | sure, it's rarely broken |
[18:49:25] | Beirdo: | OK. What I just launched now SHOULD be restored to what it was before |
[18:49:34] | Beirdo: | I'll try the tip tonight |
[18:49:43] | Beirdo: | or if I get a spare moment a bit later :) |
[18:53:22] | Beirdo: | Ok, it's not failing now at least. Should finish soon |
[18:54:57] | Seeker`: | hmm, so when enabling BD debugging, there seems to be an almost constant stream of data appearing in bluray.c, which means that it is the file buffer which is running empty |
[18:56:39] | Seeker`: | from the logs, it sends a request for data, gets 0 bytes in response and then waits for 2 seconds; I'm guessing this is the socket time out? |
[18:56:52] | Beirdo: | taking its time because someone launched a build at the same time :) |
[18:57:00] | stuartm: | hmm, subtitle colours are reversed on a DVD ripped by MakeMKV, outline is white and fill black – mplayer gets it right |
[18:57:29] | stuartm: | Beirdo: how thoughtless! |
[18:57:32] | MythBuild: | build #541 of cppcheck-master is complete: Success [build successful] Build details are at http://code.mythtv.org/buildbot/builders/cppc . . . r/builds/541 |
[18:57:48] | Beirdo: | OK, back to 178 reported |
[18:58:02] | Beirdo: | that will do for now, I'll play again tonight |
[18:58:21] | Beirdo: | meeting time! |
[18:58:32] | stuartm: | heh, mythmusic wipes out the work done in the last few days, it was down to 124 from 179 this morning |
[19:01:47] | Seeker`: | who would know about RingBuffer code? |
[19:19:53] | markk: | wagnerrp: there's a comment in the code about ipv6 – I should have mentioned in the commit that it may need fixing for ipv6. |
[19:20:30] | markk: | Seeker': have you confirmed the data from the libbluray is uninterrupted? |
[19:20:55] | Seeker`: | markk: I enabled debugging, and watched it with tail -f |
[19:22:04] | markk: | Seeker'; btw, not that it helps, it's an issue that's been around since the bluray code was written. a fix would be very much appreciated:) |
[19:22:28] | markk: | wagnerrp: I assume it's not working for you with ipv6? |
[19:24:10] | wagnerrp: | no, i dont have anything to try it with |
[19:24:32] | wagnerrp: | im just wondering in regards to fixing other things (specifically upnp) that dont work with ipv6 |
[19:25:45] | markk: | ah – ok. raop may not work – though it should just be a straight endian fix if it isn't working ( I think) |
[19:27:42] | markk: | stuartm: subtitle colours on a ripped dvd are guesswork – sometimes you get it right, sometimes you get it wrong. you don't have access to the original palette. |
[19:28:54] | Seeker`: | markk: I submitted bug #10294, the attached log shows the pause. I don't fully understand the code, but can't the backend send an EOF message / close the connection? |
[19:51:19] | davide_: | "QSqlDatabasePrivate::removeDatabase: connection 'DataDirectCon' is still in use, all queries will cease to work." I just started getting this error when running "mythbackend --testsched >/dev/null". Does anyone know what's going on? |
[20:09:58] | Seeker`: | markk: any idea where I can find the code that streams the content to the socket on the backend? |
[20:15:49] | wagnerrp: | Seeker`: talking about from frontend to backend? mythtv/programs/mythbackend/mainserver.cpp |
[20:16:00] | wagnerrp: | backend to frontend* |
[20:23:19] | Seeker`: | markk: wagnerrp should fasttimeout be set for blurays? |
[20:23:40] | wagnerrp: | no idea on that one |
[20:24:17] | danielk22 (danielk22!~danielk@96.57.9.142) has joined #mythtv | |
[20:25:48] | danielk22 (danielk22!~danielk@96.57.9.142) has quit (Client Quit) | |
[20:26:12] | danielk22 (danielk22!~danielk@96.57.9.142) has joined #mythtv | |
[20:26:48] | Seeker`: | wagnerrp: can you have a look at ringbuffer.cpp line 853/854, and compare that to www.mythtv.org/wiki/QUERY_FILETRANSFER_(Myth_Protocol)#SET_TIMEOUT |
[20:30:03] | rsiebert_ (rsiebert_!~quassel@e179130255.adsl.alicedsl.de) has joined #mythtv | |
[20:32:02] | wagnerrp: | im not sure what im supposed to be looking at |
[20:32:08] | wagnerrp: | that line is for livetv sessions, not blurays |
[20:33:26] | Seeker`: | wagnerrp: ony place I can see that sets SET_TIMEOUT, and I think it should be false for livetv anyway |
[20:33:27] | stuartm: | same reasoning though, fast transitiond |
[20:33:32] | Captain_Murdoch: | Seeker`, I don't think you're hitting the timeout. you get back a '0 bytes read' response to the last read, then it waits 2 seconds before sending the DONE, then it opens the new file right away. I think the 2-second delay is the BD code not pro-actively opening the next file when it hits EOF on the current file. I don't know if that pro-active opening is something that happens in the BD ringbuffer or not. |
[20:34:25] | Captain_Murdoch: | I don't see any FE->BE query taking more than short time in ms. |
[20:52:13] | danielk22: | Is the gcc memory usage really much better in 4.7? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36687 |
[20:53:03] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
[20:55:46] | map7_ (map7_!~map7@ppp118-209-93-114.lns20.mel4.internode.on.net) has quit (Ping timeout: 252 seconds) | |
[20:56:28] | wagnerrp: | i honestly cant say ive seen that problem since stopping compiling on my old 1GB+0GB swap frontend |
[20:57:03] | wagnerrp: | and that was only when using -j2 |
[21:01:34] | danielk22: | wagnerrp: We refactored a few mythtv files to lower their memory usage, so you shouldn't have been seeing any issues. |
[21:09:03] | danielk22: | stuartm: Yikes! mythmusic really drove up the cppcheck warnings! |
[21:10:21] | Beirdo: | that's what we get for ignoring it :) |
[21:11:05] | Beirdo: | heh. You shoulda seen it when I briefly tried cppcheck 1.52 |
[21:11:24] | danielk22: | Beirdo: How long is cppcheck taking to run these days? Fast enough that it be run on every commit? |
[21:11:27] | Beirdo: | I think we have some command-line tweakage, it spiked up to over 3000 |
[21:11:53] | danielk22: | Beirdo: yah, I ran 1.52 too.. I think that's just new error types that it's finding.. |
[21:12:13] | Beirdo: | about 9 minutes |
[21:12:27] | Beirdo: | well, most of the errors were that it couldn't find the include files |
[21:12:41] | Beirdo: | so likely some minor attention required |
[21:13:05] | Beirdo: | we could run it more often, but every commit? |
[21:13:14] | Seeker`: | Captain_Murdoch: yeah, sounds about right. I have absolutely no idea how to fix that. |
[21:13:40] | Beirdo: | the problem is, it runs on the same machine as the 64bit test compile, so it ends up being a lot slower if in parallel |
[21:14:57] | Beirdo: | it's every 2h right now |
[21:15:08] | Beirdo: | (only when changes made) |
[21:16:09] | skd5aner: | xris: scrolling through backlog – if you are curious, the release notes track which libs have been added / removed – I can't say it's 100% accurate, but I try to keep track as best as I can (it helps when devs explicitly call it out in the commit note, otherwise I track changes to .config to catch the rest) |
[21:16:26] | skd5aner: | xris: http://www.mythtv.org/wiki/Release_Notes_-_0. . . . site_Changes |
[21:17:11] | Beirdo: | danielk22: another thing to track down is the signed/unsigned warnings from the compile. I'll take a look tonight if you guys haven't got to it :) |
[21:18:04] | Beirdo: | it's nice to see the cleanliness of the code improve |
[21:18:38] | Beirdo: | danielk22: Oh, and if you want a new run sooner you can always do: |
[21:18:47] | Beirdo: | MythBuild: force build cppcheck-master now |
[21:18:48] | MythBuild: | build forced [ETA 8m24s] |
[21:18:48] | MythBuild: | I'll give a shout when the build finishes |
[21:18:51] | Beirdo: | :) |
[21:19:45] | Beirdo: | which, after a massive number of fixes, might just be what the doctor ordered |
[21:22:15] | skd5aner: | MythBuild: force build maserati now |
[21:22:15] | MythBuild: | no such builder 'maserati' |
[21:22:20] | skd5aner: | too bad |
[21:22:33] | Beirdo: | now now |
[21:22:40] | Beirdo: | don't break the buildbot :) |
[21:22:55] | skd5aner: | MythBuild: force build Me A Sandwich Now |
[21:22:55] | MythBuild: | no such builder 'Me' |
[21:23:03] | ** skd5aner had to do it ** | |
[21:24:34] | danielk22: | Beirdo: Ah, I didn't know that was possible. Very cool. |
[21:24:57] | Beirdo: | yeah, so far it's enabled :) |
[21:25:12] | danielk22: | Beirdo: Yeah, I plan to look at the compiler warnings too... The cppchecks were just something I could do on a 20 hour flight.. |
[21:25:28] | Beirdo: | ahh, yeah |
[21:25:39] | Beirdo: | good way to pass the time too :) |
[21:26:10] | Beirdo: | the cool thing is the rsync at the end is super-fast now |
[21:26:43] | Beirdo: | (more noticable on the doxygen rsync) |
[21:27:44] | MythBuild: | Hey! build cppcheck-master #544 is complete: Success [build successful] |
[21:27:44] | MythBuild: | Build details are at http://code.mythtv.org/buildbot/builders/cppc . . . r/builds/544 |
[21:28:14] | Beirdo: | nice. Down to 81 |
[21:28:19] | danielk22: | Pretty fast.. and down below a hundred again :) |
[21:28:35] | skd5aner: | 20 hour flight... geeze |
[21:29:15] | skd5aner: | can it get much longer than that? |
[21:29:35] | Beirdo: | not by much |
[21:29:44] | danielk22: | skd5aner: not much.. this was 11 timezones.. |
[21:30:10] | skd5aner: | I think 12–14 was the longest for me |
[21:30:13] | Beirdo: | that'd be about NYC-Australia or so, no? |
[21:30:40] | Beirdo: | or would that be a touch longer.. hmm |
[21:31:11] | sphery: | dblain: Out of curiosity, is it possible for us to affect the serialization format for a standard Qt type? Specifically, I'd like to include milliseconds when serializing the QDateTime for logs (but it won't make sense to do so for most other QDateTimes). Thought there might be an approach for specifying that in the datacontract or something. It's not critical--and I can always do it with a wrapper class, but just wanted to make sure I used ... |
[21:31:17] | sphery: | ... the best approach. |
[21:32:14] | sphery: | danielk22: Assuming you're not on that flight, now, have you seen http://www.gossamer-threads.com/lists/mythtv/users/500648#500648 ? Seems like that may be a typo? |
[21:32:42] | danielk22: | Beirdo: Other way around the planet JFK->HYD.. But on second thought I think JFK to AMZ would be a fair bit longer. You'd need to go 18hr hours to JP, 5hr to AU then 6hr to NZ.. |
[21:32:45] | sphery: | oh, and that can wait if you're busy... |
[21:33:18] | danielk22: | sphery: yeah, looks like a reversal of intent.. |
[21:33:30] | sphery: | if you'd like I can flip it for you |
[21:33:50] | danielk22: | I'll do it. np. |
[21:34:08] | sphery: | thx |
[21:34:33] | Beirdo: | ahh |
[21:34:38] | Seeker`: | Captain_Murdoch: do you think a valid solution would be to keep two files open, and just swap pointers? |
[21:40:29] | stuartm: | skd5aner: iirc it was something like that when I flew to Australia, a two hour stopover in Kuala Lumpur though |
[21:40:44] | stuartm: | definitely grim |
[21:42:38] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Ping timeout: 240 seconds) | |
[21:42:48] | stuartm: | googling it's between 22h 30m – 23h 30m for Heathrow to Melbourne |
[21:43:23] | Beirdo: | yeah. |
[21:43:49] | Beirdo: | my aunt used to do Toronto->Kota Kinabalu far too often |
[21:44:08] | Beirdo: | so it turned out a similar nearly all-day flight situation |
[21:50:22] | Captain_Murdoch: | Seeker`, I think the issue is that we don't know what the next file is until it's asked for. I don't know that part of the code well enough, but if it does any buffering, I'd expect it to ask for the next file ahead of time when it sees the current file is at EOF. |
[21:52:41] | Seeker`: | Captain_Murdoch: the code in bluray.c does |
[21:53:12] | Seeker`: | (know what file is next, that is) |
[21:54:46] | Captain_Murdoch: | which line range are you looking at? |
[21:54:50] | Seeker`: | (see ~ line 1173 in bluray.c – that is how you get / open the new file) |
[21:55:13] | Seeker`: | 1195–1203 does the actual opening |
[21:57:50] | stuartm: | danielk22: so the pbb update bug turned out to be unrelated to disabling the reload during playback, it just exposed a bug which had been in that code since day one |
[21:58:31] | stuartm: | the fix couldn't have been simpler, entirely disproportionate to the time I spend tracking it down :/ |
[21:58:54] | Beirdo: | isn't that usually the case? |
[21:59:34] | stuartm: | often enough, yeah :) |
[22:00:47] | Seeker`: | Captain_Murdoch: I think the code in bluray.c could be made to handle opening the new file if it were possible to pass up the 'buffer has reached EOF' message back up |
[22:04:03] | Captain_Murdoch: | Seeker`, I wonder if your 2 second delay is in BDRingBuffer::WaitForPlayer(). There's a loop in there that times out after 2 seconds. That method is called whenever the BD_EVENT_END_OF_TITLE event is sent. |
[22:06:16] | jya (jya!~jyavenard@120.148.99.54) has joined #mythtv | |
[22:06:16] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
[22:06:16] | jya (jya!~jyavenard@120.148.99.54) has quit (Changing host) | |
[22:06:26] | Seeker`: | Captain_Murdoch: I don't think it uses a BDRingBuffer |
[22:09:08] | Captain_Murdoch: | probably not it anyway, this isn't the end of a title, just a clip right |
[22:09:16] | Seeker`: | correct |
[22:09:29] | Seeker`: | I think it uses a FileBuffer, which wraps a RemoteFile |
[22:11:33] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 260 seconds) | |
[22:14:50] | danielk22: | stuartm: So that was the whole of it? I thought that commit would just be step 1 of 20 :) |
[22:16:37] | stuartm: | danielk22: that was it, at least it fixed the issue for me and I couldn't see any other issues which were directly related |
[22:19:34] | stuartm: | the change of events precipitated by the invalid date was a bit longer and more complicated than described in the commit message |
[22:19:58] | danielk22: | Cool! Honestly, I love 1 line fixes. |
[22:21:22] | xavierh (xavierh!~chatzilla@cpc1-swin3-0-0-cust274.3-1.cable.virginmedia.com) has joined #mythtv | |
[22:28:27] | stuartm: | we probably want to ignore the CdDecoder warnings for now, Paul is asking Lawrence to update his libcdio patch in the hope of getting it in for 0.25 (it's sorely needed), changes to CdDecoder might cause conflicts |
[22:28:42] | Seeker`: | Captain_Murdoch: looks like it uses a FileRingBuffer, wrapping a RemoteFile, which bluray.c uses by using file_mythiowrapper.c |
[22:28:51] | stuartm: | s/might/will/ |
[22:29:09] | MythBuild: | build #545 of master-vista-mingw-32bit is complete: Exception [exception git] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . t/builds/545 blamelist: Stuart Morgan <smorgan@mythtv.org >, John Poet <jpoet@mythtv.org >, Daniel Kristjansson <danielk@cuymedia.net > |
[22:29:24] | Captain_Murdoch: | Seeker`, yeah, I was thinking we bypassed BDRB in this case. mythiowrapper is my code/hack to support remote DVD/BD. |
[22:29:55] | stuartm: | MythBuild: force build master-vista-mingw-32bit now Stupid thing |
[22:29:56] | danielk22: | stuartm: Can you put those in the suppression list? |
[22:30:00] | MythBuild: | The build has been queued, I'll give a shout when it starts |
[22:30:07] | stuartm: | sure |
[22:30:34] | stuartm: | MythBuild: cancel build master-vista-mingw-32bit |
[22:30:46] | ** stuartm is guessing at syntax ** | |
[22:32:39] | EagleIJoe (EagleIJoe!~rockhound@d030112.adsl.hansenet.de) has joined #mythtv | |
[22:33:25] | EagleIJoe (EagleIJoe!~rockhound@d030112.adsl.hansenet.de) has left #mythtv () | |
[22:33:47] | stuartm: | danielk22: turns out it was already suppressed but recent changes had changed the line number |
[22:35:00] | EagleIJoe (EagleIJoe!~rockhound@d030112.adsl.hansenet.de) has joined #mythtv | |
[22:35:21] | EagleIJoe (EagleIJoe!~rockhound@d030112.adsl.hansenet.de) has quit (Client Quit) | |
[22:35:43] | Seeker`: | Captain_Murdoch: My idea was to create a secondStream pointer, and doing 1 block of read in to that stream from the next title, then when bluray.c actually hits EoF, it swaps secondStream to the main stream |
[22:36:29] | Beirdo: | hmm |
[22:36:45] | Seeker`: | that way all of the file setup is done, and there is some data there waiting |
[22:37:07] | Beirdo: | MythBuild: help |
[22:37:07] | MythBuild: | Get help on what? (try 'help <foo>', or 'commands' for a command list) |
[22:37:14] | Beirdo: | MythBuild: commands |
[22:37:14] | MythBuild: | buildbot commands: commands, dance, destroy, excited, force, hello, help, last, list, mute, notify, source, status, stop, unmute, version, watch |
[22:37:21] | Captain_Murdoch: | I think we've kept that file pretty much stock until now. pre-opening the next clip might be the simplest way around the issue though since the code doesn't assume there's any kind of buffering in the file_* methods. |
[22:37:27] | Beirdo: | MythBuild: help force |
[22:37:28] | MythBuild: | Usage: force build [--branch=branch] [--revision=revision] <which> <reason> – Force a build |
[22:37:35] | Beirdo: | I don't see a cancel. |
[22:37:37] | Seeker`: | Captain_Murdoch: it doesn't afaik |
[22:37:38] | Beirdo: | that's odd |
[22:37:43] | Beirdo: | ooohhh |
[22:37:47] | Beirdo: | MythBuild: help stop |
[22:37:47] | MythBuild: | Usage: stop build <which> <reason> – Stop a running build |
[22:37:47] | stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has quit (Remote host closed the connection) | |
[22:37:51] | Beirdo: | ahhh |
[22:38:10] | Beirdo: | MythBuild: stop build master-vista-mingw-32bit now |
[22:38:10] | MythBuild: | build 546 interrupted |
[22:38:15] | Beirdo: | there we go |
[22:38:18] | MythBuild: | build #546 of master-vista-mingw-32bit is complete: Exception [exception shell configure] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . t/builds/546 blamelist: Stuart Morgan <smorgan@mythtv.org > |
[22:38:28] | MythBuild: | build forced [ETA 1h23m41s] |
[22:38:28] | MythBuild: | I'll give a shout when the build finishes |
[22:38:59] | Beirdo: | heh, it woulda started anyways, but that works |
[22:39:21] | MythBuild: | build #547 of master-vista-mingw-32bit is complete: Exception [exception git] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . t/builds/547 |
[22:39:24] | danielk22: | Seeker`: I don't think you really need to get super complicated.. Just doing a read from the next file 30 seconds before you need it and tossing the data is sufficient. That will put it in the OS cache and will allow it to be reread very quickly when it is actually needed. |
[22:39:41] | Beirdo: | I need to smack windows around again, it seems |
[22:40:04] | Beirdo: | and it's starting again. |
[22:40:28] | MythBuild: | build #548 of master-vista-mingw-32bit is complete: Exception [exception git] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . t/builds/548 blamelist: Paul Harrison <pharrison@mythtv.org >, Mark Kendall <mkendall@mythtv.org > |
[22:40:45] | Beirdo: | OK, time to kick it. |
[22:41:23] | clever: | maybe something didnt fully exit and is holding the file/dir open |
[22:43:00] | Beirdo: | It's windows, it needs to be reminded how to behave sometimes |
[22:43:30] | Beirdo: | MythBuild: force build master-vista-mingw-32bit now, bunghole. |
[22:43:30] | MythBuild: | build forced [ETA 1h23m41s] |
[22:43:30] | MythBuild: | I'll give a shout when the build finishes |
[22:43:46] | clever: | lol |
[22:44:08] | Seeker`: | danielk22: is that really sufficient? because it is reading over the network |
[22:46:38] | danielk22: | Seeker`: The buffering in mythtv should be able to deal with network latencies. I'm assuming it's the spin up of a new file reader that's slowing you down too much; most of that spin up is filling up the buffers. |
[22:46:46] | stuartm (stuartm!~stuartm@cpc1-derb9-0-0-cust441.8-3.cable.virginmedia.com) has joined #mythtv | |
[22:46:47] | stuartm (stuartm!~stuartm@cpc1-derb9-0-0-cust441.8-3.cable.virginmedia.com) has quit (Changing host) | |
[22:46:47] | stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has joined #mythtv | |
[22:47:11] | Beirdo: | heya, stuartm ... the command you were looking for seems to be "stop build". |
[22:47:12] | Seeker`: | bah, it only takes 0.2 seconds between requesting the new file and getting data back |
[22:47:18] | Seeker`: | so that won't fix it |
[22:47:18] | danielk22: | Seeker`: In any case it should be easy to test. |
[22:47:23] | Beirdo: | I kicked the slave in the head, and restarted the build |
[22:48:24] | Captain_Murdoch: | Seeker`, I think having the next clip open would be fairly non-invasive if handled as part of _open_m2ts() , _change_angle(), and _close_playlist(), and bd_close() |
[22:49:44] | Seeker`: | Captain_Murdoch: i'm not sure if it will fix the problem, thinking about it |
[22:50:40] | Captain_Murdoch: | Seeker`, if you have the next file already open (and hence it's buffers already full), then switchover should be immediate since it's all local reads. |
[22:50:56] | Seeker`: | do the buffers autmatically fill when you open the file? |
[22:51:10] | Seeker`: | or is there an easy way to say 'fill this buffer'? |
[22:52:04] | stuartm: | Beirdo: cool, there didn't seem much point in queuing a second build, especially when that one is so slow |
[22:57:29] | Captain_Murdoch: | Seeker`, if we start it with the readahead thread running it should start reading for us. |
[22:58:01] | Seeker`: | Captain_Murdoch: cool, I'll start having a look then |
[22:59:11] | ** stuartm just noticed that he suppressed the cddecoder stuff moments after Paul completely removed it ** | |
[22:59:36] | Beirdo: | nice timing :) |
[23:00:51] | stuartm: | I knew he was planning to commit the patch but not that he did it two minutes before I hit 'return' |
[23:02:20] | Captain_Murdoch: | Seeker`, could add a nextfp pointer in BD_STREAM and check that whever we call _close_m2ts to see if we need to also call a _close_next_m2ts() if one is open. you might want to run it by iamlindoro since he is the main person for that area of the code. we've tried to keep the changes to a minimum except for the remote support I believe. |
[23:03:41] | davide_: | Beirdo: Did you see my earlier post about seeing "QSqlDatabasePrivate::removeDatabase: connection 'DataDirectCon' is still in use, all queries will cease to work." when running "mythbackend --testsched?" It appears the DataDirectCon is being closed twice, once in Scheduler::~SCheduler() and again in MDBManager::CloseDatabases(). Is there any harm from removing the close from ~Scheduler()? |
[23:03:59] | Seeker`: | Captain_Murdoch: not sure you'll always need to call close_next though, will you? |
[23:04:07] | MythBuild: | build #122 of master-osx-snow-leopard is complete: Failure [failed compile_2] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . d/builds/122 blamelist: Paul Harrison <pharrison@mythtv.org >, Mark Kendall <mkendall@mythtv.org > |
[23:04:34] | Seeker`: | because in the middle of the movie you'd call open(file), read(file)...read(file), close(file), open(file2) etc. |
[23:04:50] | Seeker`: | so it'd only be when you reach the end of the disk that you would need to close the next one |
[23:05:03] | Beirdo: | davide_: not sure. I think that danielk22 may have a better grip on the current database shutdown code, he's tweaked it a couple times since I looked at it last. |
[23:05:07] | Seeker`: | s/disk/title |
[23:05:32] | Beirdo: | if that's during shutdown, there's likely no harm in disabling one or the other |
[23:05:55] | Beirdo: | but I'm not sure at this point, I'd have to go brush up on the latest code |
[23:08:34] | davide_: | danielk22: see bit about DataDirectCon above. |
[23:09:21] | dblain: | sphery: regarding custom formatting of specific properties in the serialization code... It does not currently support it. The best we could do is add ClassInfo to the datacontract which we could extract and use during serialization. |
[23:09:55] | davide_: | Beirdo: I tried it and didn't see any errors, but then, I didn't do anything exotic either. |
[23:10:02] | dblain: | It wouldn't be too difficult to implement, but I'd want to think about the best way to structure the classinfo data to allow for the most flexability |
[23:10:50] | danielk22: | davide_: The teardown in ~Scheduler prolly isn't needed anymore. But let me take a look. |
[23:11:21] | sphery: | dblain: If you prefer, I could just create a class with a QDateTime member and just have a toString() that uses the format I want... Would be simple enough and should work, right? |
[23:11:54] | Beirdo: | thanks, danielk22. :) I really need to refresh my brain on the changes there so I'm not so clueless :) |
[23:12:32] | davide_: | danielk22: somebody (you?) removed the call to CloseSchedCon() that used to be there. I suspect it's the same issue. |
[23:12:45] | danielk22: | davide_: Strangely I'm not seeing the error message you are. |
[23:13:01] | dblain: | sphery: That would work in the short term, but having a way to give rendering hints (metadata about the properties) would be a cleaner long term solution |
[23:13:07] | Beirdo: | could well be a race condition related to processor speed or the like |
[23:13:23] | Beirdo: | multithreaded fun |
[23:13:43] | danielk22: | davide_: Basically, the connections are all torn down in the thread epilog now, so explicitly closing the connections isn't necessary. |
[23:14:01] | sphery: | dblain: ok, I'm just using seconds resolution for initial development, but may extend it... Thanks for the info. |
[23:14:09] | danielk22: | That avoid all the issues we saw with closing connections in a different thread than the one that they were created in.. |
[23:14:16] | danielk22: | s/avoid/avoids/ |
[23:14:31] | Beirdo: | which plagued us quite a bit |
[23:14:53] | davide_: | danielk22: FWIW, I just started seeing it. Ooh, now that I think of it, Debian/testing recently did a Qt update. I bet that's when I started seeing the new warning. |
[23:22:57] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit () | |
[23:23:00] | danielk22: | davide_: Can you send a log? It should actually be harmless to call CloseDDCon() before CloseDatabases(). |
[23:27:15] | davide_: | danielk22: It's in the mail. |
[23:28:49] | danielk22: | davide_: got it |
[23:30:18] | rsiebert_ (rsiebert_!~quassel@e179130255.adsl.alicedsl.de) has quit (Ping timeout: 272 seconds) | |
[23:32:36] | Seeker`: | Captain_Murdoch: bah, I cant test this properly; my dev machine isn't wired to my backend :( |
[23:41:11] | Seeker` (Seeker`!~cjo20@unaffiliated/seeker) has quit (Ping timeout: 252 seconds) | |
[23:47:16] | Seeker` (Seeker`!~cjo20@host86-160-233-91.range86-160.btcentralplus.com) has joined #mythtv | |
[23:47:16] | Seeker` (Seeker`!~cjo20@host86-160-233-91.range86-160.btcentralplus.com) has quit (Changing host) | |
[23:47:16] | Seeker` (Seeker`!~cjo20@unaffiliated/seeker) has joined #mythtv | |
[23:50:54] | Seeker` (Seeker`!~cjo20@unaffiliated/seeker) has quit (Read error: Operation timed out) | |
[23:52:17] | Seeker` (Seeker`!~cjo20@host86-160-233-91.range86-160.btcentralplus.com) has joined #mythtv | |
[23:52:18] | Seeker` (Seeker`!~cjo20@host86-160-233-91.range86-160.btcentralplus.com) has quit (Changing host) | |
[23:52:18] | Seeker` (Seeker`!~cjo20@unaffiliated/seeker) has joined #mythtv | |
[23:59:50] | wagnerrp: | danielk22: yeah, this would have been similar time frame to you opening that report, 2008–2009, building 0.21 |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.