| Friday, September 6th, 2013, 00:15 UTC | ||
| [00:15:00] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 245 seconds) | |
| [00:25:00] | Chutt (Chutt!~ijr@cpe-76-190-199-73.neo.res.rr.com) has quit (Read error: Connection reset by peer) | |
| [00:30:56] | DJDan (DJDan!~djdan@115-64-177-188.static.tpgi.com.au) has quit (Remote host closed the connection) | |
| [01:01:26] | NightMonkey (NightMonkey!~NightrMon@173-164-139-193-SFBA.hfc.comcastbusiness.net) has joined #mythtv | |
| [01:01:37] | NightMonkey (NightMonkey!~NightrMon@173-164-139-193-SFBA.hfc.comcastbusiness.net) has quit (Changing host) | |
| [01:01:37] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [01:32:37] | _nd47_ (_nd47_!6400b470@gateway/web/freenode/ip.100.0.180.112) has quit (Quit: Page closed) | |
| [01:44:26] | stichnot (stichnot!~stichnot@adsl-68-127-103-225.dsl.pltn13.pacbell.net) has joined #mythtv | |
| [01:44:26] | stichnot (stichnot!~stichnot@adsl-68-127-103-225.dsl.pltn13.pacbell.net) has quit (Changing host) | |
| [01:44:26] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [02:15:17] | knightr: | what exactly is browsable used for in the video filters? |
| [02:22:41] | gigem: | jpagq: I have a few problems with your patch. First, not everyone changes time at 2am local time. and maybe not even on Sunday. I believe the zones in Europe all change at the same UTC time. Second, not everyone changes by 60 minutes. I think there is at least one zone that only changes by 30 minutes. Who knows, but there might even be some that change by more than 60 minutes. Third, I really don't like |
| [02:22:43] | gigem: | creating two program entries and consequently two recordings when there is ambiguity. I'd much rather have one program that begins at the earliest ambiguous time and ends at the latest ambiguous time. Unfortunately, it doesn't look that's easy to do right now since most implementations usually always assume the earliest or latest time when converting. In Qt's case, it currently varies by platform. It |
| [02:22:45] | gigem: | sounds like there are plans to let the programmer choose the behavior for individual conversions, but that won't go in until at lease version 5.2. |
| [02:26:50] | _nyloc_ (_nyloc_!~quassel@p3EE2D2A4.dip0.t-ipconnect.de) has joined #mythtv | |
| [02:31:07] | nyloc (nyloc!~quassel@p3EE2C0C9.dip0.t-ipconnect.de) has quit (Ping timeout: 264 seconds) | |
| [02:42:11] | peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Ping timeout: 240 seconds) | |
| [02:47:04] | peper03 (peper03!~peper03@mythtv/developer/peper03) has joined #mythtv | |
| [02:56:07] | robink_ (robink_!~quassel@unaffilated/robink) has joined #mythtv | |
| [02:57:02] | robink (robink!~quassel@unaffilated/robink) has quit (Ping timeout: 240 seconds) | |
| [03:03:40] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!) | |
| [03:07:52] | Chutt (Chutt!~ijr@cpe-76-190-199-73.neo.res.rr.com) has joined #mythtv | |
| [03:10:06] | dgeary2 (dgeary2!~debian@pa49-187-80-151.pa.nsw.optusnet.com.au) has joined #mythtv | |
| [03:18:03] | jya: | gigem: I know of one Australian state changing by only 30 minutes on DST |
| [03:20:18] | dgeary2_ (dgeary2_!~debian@pa49-187-80-132.pa.nsw.optusnet.com.au) has joined #mythtv | |
| [03:22:13] | dgeary2 (dgeary2!~debian@pa49-187-80-151.pa.nsw.optusnet.com.au) has quit (Ping timeout: 248 seconds) | |
| [03:24:11] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 245 seconds) | |
| [03:25:38] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [03:29:38] | kwmonroe (kwmonroe!~kwmonroe@32.97.110.52) has joined #mythtv | |
| [03:29:38] | joki (joki!~joki@p54863EB1.dip0.t-ipconnect.de) has quit (Ping timeout: 264 seconds) | |
| [03:32:14] | kwmonroe` (kwmonroe`!kwmonroe@nat/ibm/x-mkmpgbmfdaqglnsi) has quit (Ping timeout: 240 seconds) | |
| [03:33:48] | dgeary2_ (dgeary2_!~debian@pa49-187-80-132.pa.nsw.optusnet.com.au) has quit (Quit: Ex-Chat) | |
| [03:34:37] | joki (joki!~joki@p54863A8D.dip0.t-ipconnect.de) has joined #mythtv | |
| [04:01:58] | knightr: | jpabq, Hi! Themes which still have OSD menu editor entries in them have stuff that was deprecated in 0.24? |
| [04:04:13] | knightr: | (in 35a9c3859 to be exact...) |
| [04:18:55] | gigem: | jya: Yeah, now that you mention it, I remember Aussie time zones being really odd. Due to differences in DST between the north and south, there can be like 5 different local times in a country that is only wide enough for 3 typical time zones. |
| [04:19:51] | jya: | each state have their own DST. time difference between Adelaide and Melbourne is 30 minutes, QLD doesn't have DST etc... |
| [04:34:09] | NightMonkey (NightMonkey!~NightrMon@173-164-139-193-SFBA.hfc.comcastbusiness.net) has joined #mythtv | |
| [04:34:09] | NightMonkey (NightMonkey!~NightrMon@173-164-139-193-SFBA.hfc.comcastbusiness.net) has quit (Changing host) | |
| [04:34:10] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [04:35:18] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Read error: Connection reset by peer) | |
| [05:02:48] | jpabq: | gigem: I thought about leaving out the check for hour() == 1. That patch doesn't assume Sunday. As far as your other concerns, I can't think of an efficient way of handling the entire planet. |
| [05:03:58] | jpabq: | Changing it record two hours instead of two 1 hours — I guess that would be okay. Personally, I would prefer it record the two 1 hours blocks, since that would make it easier to delete one of them, if I really only ended up wanted one of the "1am" recordings. |
| [05:05:34] | jpabq: | I did try to look up if Qt had proper timezone support, and saw that it was scheduled for 5.1 |
| [05:08:30] | jpabq: | Leaving out the hour() == 1 check would fix for most of the work, but you are right — it would not handle New Zealand based on this http://www.timeanddate.com/time/dst/events.html |
| [05:08:42] | jpabq: | s/work/world/ |
| [05:09:43] | jpabq: | Actually, I guess it would work for most of New Zealand. Just not the Chatham Islands. |
| [05:21:41] | jpabq: | It looks like everywhere that does a time change, does it by a full hour. There are countries with .5 time-zones, but even they change time one-the-hour local time (like Iran). Chatham Islands is the only exception I can find. |
| [05:30:47] | jpabq: | One scenario I tested was with a manual record set for 1:30am – 2:00am. That patch handled that just fine — I ended up with 1:30am-1:00am (30 minute) and 1:30am-2:00am (30 minute) recordings. The problem with trying to just get one recording, is you would end up with a 90 minute recording in that situation. |
| [05:34:06] | Tobbe5178 (Tobbe5178!~asdf@h104n2-sv-a13.ias.bredband.telia.com) has joined #mythtv | |
| [05:55:25] | SteveGoodey (SteveGoodey!~steve@host109-158-215-102.range109-158.btcentralplus.com) has joined #mythtv | |
| [05:59:46] | pentanol (pentanol!~pentanol@unaffiliated/pentanol) has joined #mythtv | |
| [06:02:30] | pentanol: | hello, someone uses Prolink PV-B420SPL on linux ? |
| [06:07:31] | SteveGoodey: | pentanol: You might want to try mythtv-users. This is a dev channel. :-) |
| [06:14:54] | FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has joined #mythtv | |
| [06:19:28] | SteveGoodey (SteveGoodey!~steve@host109-158-215-102.range109-158.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [06:27:30] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 245 seconds) | |
| [06:32:13] | pentanol: | ok |
| [06:32:16] | pentanol (pentanol!~pentanol@unaffiliated/pentanol) has left #mythtv () | |
| [07:21:00] | natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has quit (Ping timeout: 276 seconds) | |
| [07:52:26] | wolfgang (wolfgang!~wolfgang@188-195-72-139-dynip.superkabel.de) has quit (Ping timeout: 264 seconds) | |
| [08:49:41] | FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has quit (Quit: FabriceMG) | |
| [08:50:13] | FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has joined #mythtv | |
| [09:16:59] | paul-h (paul-h!~Paul@2.219.20.71) has joined #mythtv | |
| [09:18:01] | dekarl1 (dekarl1!~dekarl@p4FCEFB8F.dip0.t-ipconnect.de) has joined #mythtv | |
| [09:21:14] | dekarl (dekarl!~dekarl@p4FCEEFE4.dip0.t-ipconnect.de) has quit (Ping timeout: 264 seconds) | |
| [09:51:21] | stichnot (stichnot!~stichnot@adsl-68-127-103-225.dsl.pltn13.pacbell.net) has joined #mythtv | |
| [09:51:21] | stichnot (stichnot!~stichnot@adsl-68-127-103-225.dsl.pltn13.pacbell.net) has quit (Changing host) | |
| [09:51:21] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [10:46:41] | IReboot (IReboot!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has joined #mythtv | |
| [10:53:17] | FabriceMG1 (FabriceMG1!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has joined #mythtv | |
| [10:54:47] | FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has quit (Ping timeout: 246 seconds) | |
| [10:58:09] | danielk221 (danielk221!~danielk22@exchange.wgen.net) has joined #mythtv | |
| [11:23:24] | jya: | jpabq: I thought that the whole point of using UTC would be that we don't have to handle time changes ? |
| [11:27:56] | danielk221: | I think this is for manual time based records. i.e. "record channel X from 2am-3am every day". |
| [11:30:20] | danielk221: | It's an edge case for regular users who will mostly be using program guide based recording. But for Digital Nirvana this is what most customers want. They especially want to record things even when their program guide system doesn't handle time changes elegantly. |
| [11:42:10] | jya: | danielk22: thanks... got your email. I'm in NYC today for the day; and probably tomorrow, but I don't know yet when exactly |
| [11:44:53] | danielk221: | jya: I'm pretty flexible Saturday |
| [12:00:24] | jya: | http://www.gizmodo.com.au/2013/09/you-can-own . . . for-just-45/ |
| [12:02:58] | jya: | hardware spec here: http://imx.solid-run.com/wiki/index.php?title=CuBox-i_Hardware |
| [12:07:49] | stuartm: | could make a good frontend, wonder what the hardware decoding api is |
| [12:14:32] | dekarl-work (dekarl-work!51c8c614@gateway/web/freenode/ip.81.200.198.20) has joined #mythtv | |
| [12:16:37] | dekarl-work: | danielk22: for the use case "record even when DST handling is broken", can these schedules simply be setup in UTC? I've been trying various fixups to reverse DST handling bugs and its always a one-off solution per channel/year |
| [12:18:07] | dekarl-work: | how are the schedules set up if its not based on the guide? simply one recording per hour (or a different time span)? |
| [12:20:37] | danielk221: | dekarl-work: jpabq: For Digital Nirvana it probably would make sense to set up the recording rules in UTC. For our regular manual records we don't want that because manual recording's primary use is to record programs that air at a specific time in local time. |
| [12:21:24] | danielk221: | dekarl-work: When I was at DN the standard config was one recording per hour per channel. |
| [12:24:37] | dekarl-work: | danielk221: if regular use is Joe Average, who should usually be using guide data, then I'm happy to leave the manual, local time based, recordings in an undefined state when they intersect with time span of the DST switch. (what a sentence ;) |
| [12:25:23] | dekarl-work: | actually I don't know of any time handling library which will handle stuff like 2a o'clock vs 2b o'clock properly |
| [12:26:23] | danielk221: | dekarl-work: yeah, it's definitely an edge case. |
| [12:29:00] | dekarl-work: | IMHO the broken state of guide data around the DST switch results from no one wanting to invest into fixing the issues when there is so little gain. Which is very hard to fix or change from downstream. |
| [12:29:24] | dekarl-work: | it is not because it would be particularly hard to fix the issues |
| [12:48:17] | stuartm: | ah feck, recording I made a week ago failed halfway through |
| [12:52:34] | stuartm: | interesting issue discovered through that though – when selecting "Delete and allow re-record" expectation is that it will re-record, but that can't happen if we've already automatically deleted the 'Find one' schedule associated with it |
| [12:54:01] | stuartm: | we probably should delete "Find one" rules until the recording associated with them is deleted |
| [12:54:04] | stuartm: | shouldn't |
| [12:58:00] | gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has quit (Quit: Leaving) | |
| [12:59:42] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv | |
| [12:59:42] | stichnot: | stuartm: if we did that in the simple/naive way, I would have dozens of those "Find one" rules hanging around, which be messy |
| [13:00:24] | stuartm: | right, they should be kept but remain inactive unless we specify 'Allow rerecord' |
| [13:00:53] | stichnot: | so either those leftover rules should be "hidden", or maybe it would be possible to re-synthesize them when you "delete and allow re-record" |
| [13:02:27] | stichnot: | But I get it — countless times I've had to go and recreate the "find one" rule, after being perplexed that "delete and re-record" didn't just work |
| [13:11:53] | stichnot: | (ok, thinking about it more, I guess there's no way to synthesize the original recording rule, thanks to all the options that might have been originally set) |
| [13:12:44] | sphery: | stuartm: better approach would be to offer a choice to create a new rule for it, so the old rule doesn't hang around and slow down the scheduler and create a mess for users to look through (I have, literally, about 800 recordings from old find ones) |
| [13:13:38] | sphery: | stuartm: you can currently do this by selecting the recording, going to Scheduling options|Edit recording rule or something like that (or, IIRC, hitting E for edit or C for custom edit) |
| [13:15:34] | sphery: | stuartm: but because users don't seem to get that "Delete and *allow* re-record" is not the same as "Delete and re-record", the way I see it working to avoid confusion and make it easier for users is they select "Delete and allow re-record" and when we pop up the confirmation window, we explicitly say, "This show will not be re-recorded unless you have a rule to record it." and then give them a button along with the yes/no to create a rule ... |
| [13:15:35] | danielk221: | stuartm: Was the recording marked as failed by MythTV? |
| [13:15:40] | sphery: | ... which takes them to the schedule editor |
| [13:16:12] | stuartm: | danielk221: no, after looking at the logs it failed because the backend segfaulted |
| [13:16:21] | danielk221: | oh, yikes! |
| [13:23:40] | stuartm: | thinking about it, we can mark recordings as failed for that scenario too by having the backend check on startup whether the recording completed (simple flag in recorded table) |
| [13:34:36] | danielk221: | I'd rather fix the segfault :) |
| [14:25:54] | FabriceMG1 (FabriceMG1!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has quit (Quit: FabriceMG1) | |
| [14:45:27] | gigem: | jpabq: Even with removing the hour() == 1 check, your patch won't work on platforms where the local to UTC conversion assumes the latter ambiguous local time. In those cases, your first recording would second possible program and your second recording would be for an hour after that. Really, I'd rather just leave it as is and tell the user to be wary of entering a potentially ambiguous start time for a |
| [14:45:29] | gigem: | recurring manual recording. |
| [14:45:31] | gigem: | danielk221, dekarl-work: Recurring manual rules have to be based on local time. Would you really want your daily 6pm recording to automatically shift to 5pm or 7pm when the time changes? |
| [14:45:33] | gigem: | stuartm, stichnot: sphery beat me to suggesting the creation of a new rule. Why is choosing allow re-record for a recording from a find one rule any more special than for one from a single rule or when the user has already deleted the rule? |
| [14:45:39] | gigem: | danielk221, dekarl-work: Recurring manual rules have to be based on local time. Would you really want your daily 6pm recording to automatically shift to 5pm or 7pm when the time changes? |
| [14:45:41] | gigem: | stuartm, stichnot: sphery beat me to suggesting the creation of a new rule. Why is choosing allow re-record for a recording from a find one rule any more special than for one from a single rule or when the user has already deleted the rule? |
| [14:46:14] | gigem: | Sorry about the duplicate post — copy and paste error. |
| [14:46:44] | stuartm: | not saying it's any more special, that was simply the example I used |
| [14:48:29] | stuartm: | I don't, in general delete rules before for series/films that I'm interested in before I've finished watching all the recordings, neither do I use single rules because they are too inflexible, so 'Find One' was the particular case most relevant in my case |
| [14:48:56] | knightr: | what exactly is browsable used for in the video filters? Seems like the idea is that the video is not shown in a list but why was it added? |
| [14:49:04] | dekarl-work: | gigem, yes. But is there a problem with Recurring manual rules that intersect the DST switch time span? And if so, is there anything sensible that we can do about it? |
| [14:49:39] | stuartm: | and I'm not against it needing to create a new rule, but it adds an extra series of steps that could become irritating |
| [14:50:45] | stuartm: | knightr: I assume because some people had videos in directories that they didn't want others to see – i.e. they were too lazy to move them to another directory which wasn't accessible to mythtv |
| [14:50:45] | wolfgang (wolfgang!~wolfgang@178-27-130-87-dynip.superkabel.de) has joined #mythtv | |
| [14:51:31] | stuartm: | I really don't see the point in the browsable filter, it would make things simpler for everyone to ditch it |
| [14:52:16] | gigem: | dekarl-work: No, I don't think there any thing sensible we can do right now. Qt apparently has plans to add support for determining when there is a problem, but that's for Qt 5.x. I'd hoped libc might have something, but I couldn't find it. That pretty much leaves finding and parsing time zone files ourselves and I don't consider that sensible. |
| [14:52:57] | stuartm: | stuarta: are you still running 0.26? |
| [14:53:16] | gigem: | stuartm: Creating a new find one rules with the "This episode" filter set should be mostly invisible to the user. |
| [14:54:32] | stuarta: | stuartm: me, no. upgraded to 0.27 a few weeks back |
| [14:54:34] | stuartm: | gigem: if it's done automatically, behind the scenes for the user, then that's fine by me – others might complain that their original preferences e.g. priority/storage location weren't honoured, but it wouldn't bother me |
| [14:54:38] | stuartm: | stuarta: nuts |
| [14:54:57] | stuartm: | is anyone in the UK still running 0.26? I need someone to check whether mheg (Red Button) is still working on BBC channels |
| [14:55:29] | stuartm: | stopped working here, but I'm not sure whether it's due to something committed to master/0.27 |
| [14:56:24] | stuartm: | doesn't help that using git am preserves the _original_ commit date, meaning commits from LVR which I pushed just last week seem from the git log to have been made 2 years ago >:( |
| [14:56:46] | gigem: | stuartm: Right, it wouldn't bother me either. I suppose if someone really cared that much, there could be a "Re-record with options" button that sends them to the schedule editor. |
| [14:57:09] | knightr: | stuartm, thank you! If we ever add multi-user support that setting that could be replaced by having the possibility to decide which user(s) can see the video. For the situation you describe that would probably be a suitable replacement... |
| [14:58:58] | gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has joined #mythtv | |
| [15:05:05] | sphery: | knightr: The truth is, I have a feeling that browsable was added back in ancient days as a way for people to hide the ".nfo" files, etc., that thieves use to take credit for stealing and making available pirated video, or for video split into 2 700MB CD-sized parts (for archival, of course, not because it's stolen!) so that you could make the 2nd part not browsable, or for "auxilliary" files like external subtitle files (which you get after ... |
| [15:05:11] | sphery: | ... painstakingly OCR'ing the image-based subtitles on the DVD you ripped--not because you downloaded an illegal copy of the video). |
| [15:05:42] | sphery: | that said, I'm all for removing it... if users want to have garbage in their directories where they store the videos, they can create an alternate clean view using symlinks for Video Library |
| [15:06:46] | stuarta: | stuartm: i could always spin up 0.26 on my dev instance |
| [15:06:47] | gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has quit (Remote host closed the connection) | |
| [15:07:05] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 245 seconds) | |
| [15:07:07] | stuarta: | in fact i think i've even still got it built on the backend |
| [15:07:20] | dekarl-work: | sphery huh? Whats wrong with having multiple files per video? Thats what most home video folders will look like with .mxml files to record the "actors" so you can easily find videos with aunt mary ;) |
| [15:07:42] | stuarta: | heh, i've got 0.24, 0.25, 0.26, 0.27 and master all built and in place |
| [15:09:28] | sphery: | stuartm: "Delete and allow re-record" shouldn't just automatically create new rules, though. I have my system record every new series that airs and after it's cancelled or after it gets bad reviews or after a couple seasons when I decide I will never watch it, I delete and allow re-record the entire series I've recorded so far. That way, if I ever decide to record it (for me or someone else), it will, plus that way MythTV remembers that I ... |
| [15:09:34] | sphery: | ... haven't watched the show, plus it doesn't add hundreds (thousands over the years, probably) of episodes that say they should be duplicate checked for no benefit. |
| [15:09:47] | sphery: | So, if it actually created new rules automatically, I'd end up getting rules that I don't want. |
| [15:10:11] | SteveGoodey (SteveGoodey!~steve@host109-158-215-102.range109-158.btcentralplus.com) has joined #mythtv | |
| [15:11:08] | sphery: | dekarl-work: Does anyone actually use mxml files? I thought that was a half (or less?) functional hack that no one ever decided to finish? That said, since it's "Myth XML" (i.e. specific to MythTV), we could easily just ignore those when we have a matching video for it. |
| [15:11:23] | sphery: | ignore for browsing that is |
| [15:11:37] | knightr: | sphery, thank you! so the idea behind that setting was to hide files for whichever reason (not video files or videos they did not want other people to see easily) from view... for the "not video files" aspect we could hide files extensions we don't know how to play... |
| [15:12:13] | jpabq: | gigem: I understand what you are saying. |
| [15:12:14] | dekarl-work: | sphery: nvm just seeing that this was about hiding videos, not all kinds of files. I'm for removing that, too. If someone has legitimate split files they can merge them into a nice mkv so seeking backwards works properly |
| [15:12:15] | knightr: | (or as you said we know we can't play...) |
| [15:12:24] | stuartm: | sphery: so "Delete and re-record" in addition to "Delete and allow re-record" |
| [15:12:30] | sphery: | yeah, that's the idea... I think we have some kind of "only show known file extensions" settings, too |
| [15:13:14] | sphery: | er, files with known extensions, that is |
| [15:14:09] | sphery: | stuartm: that would work (though I still think it should pop up the schedule editor--after setting up a reasonable "default" rule, such as "this episode" for episodic or find one for movie or ...) so that users can set the appropriate options |
| [15:14:19] | dekarl-work: | lets get the refactoring of the recording/video tables in so we can track collections of files that make up one movie. (e.g. original MPEG-2 Bluray files + H.264 for iPad conversion + the Poster, etc) |
| [15:15:54] | sphery: | so the schedule editor is started with an unsaved rule that should work, but allows them to change it if we didn't guess right (rather than making them assume, "MythTV took care of everything," and then complaining when it doesn't work the way they wanted because we made an this episode rule but they actually wanted a new any time rule) |
| [15:16:44] | sphery: | dekarl-work: just have to rework the schema for the 8th and 9th time before I'll be ready to put that in (everyone keeps asking for additional changes) |
| [15:17:16] | stuartm: | sphery: I just think that's a source of irritation, often when I'm deleting and allowing re-record it's to more than one recording at once e.g. the driver failed and a whole evening's recordings were zero byte |
| [15:17:37] | stuartm: | I don't want to cleanup and get back on track with as few button presses as possible |
| [15:17:38] | sphery: | and I have 2 pretty major ones on the list to do... then have to put the schema in, then have to port the data to the new schema, then have to change all the code to work with the new schema... don't expect it sooner than a week from now. ;) |
| [15:17:57] | dekarl-work: | actually I do use mxml for my dads Diaporamas (professional stuff for tourism bureaus etc) from the 1970s and 1980s. No chance to get them on themoviedb :) and due to stupid licensing (no one thought of youtube in the 70s and to secure the right for the music) I can't post them to the internet. |
| [15:18:18] | stuarta: | stuartm: i probably can't do any 0.26 regresssion testing until monday at the earliest though |
| [15:18:55] | stuartm: | I've tried some old BBC samples I had around and it's not working with them either, so it definitely appears to be a regression |
| [15:18:58] | sphery: | stuartm: I wouldn't argue if you want it to be automatic--as long as you field all the complaints about, "The code didn't read my mind correctly!" |
| [15:20:01] | sphery: | I'll probably keep using "allow re-record", anyway, because I can't remember the last time I deleted something and allowed re-record and wanted it to re-record and didn't already have a rule for it in place. |
| [15:20:36] | dekarl-work: | wrt testing of MHEG, i just got a mail from the Opencaster people some days ago, might be useful for testing http://en.wikipedia.org/wiki/OpenCaster |
| [15:20:43] | sphery: | (and, speaking of which, the other challenge with making it automatic is trying to identify if another rule already covers it--especially with customs, etc.) |
| [15:21:18] | dekarl-work (dekarl-work!51c8c614@gateway/web/freenode/ip.81.200.198.20) has quit (Quit: TGIF! see you later) | |
| [15:21:46] | sphery: | so it's possible the automatic one would "shadow" an existing one that had the options the user wanted... but that's probably way beyond the level we need to be concerned about (and just assume the user has something of an understanding of what's happening) |
| [15:23:20] | sphery: | (so, yeah, you can make it automatically create a new rule, as long as there's an option that doesn't create a new rule, too--and it's a step forward in usability from current, even if there will be edge cases or invalid user assumptions that result in complaints (as we get plenty of complaints with the existing setup)) |
| [15:25:15] | stuartm: | well this is why my first suggestion was to keep the old rule around, that not only keeps the old options in place but avoids the necessary complexity of determining if the new rule overlaps with the existing rule |
| [15:26:12] | stuartm: | there's nothing inherently wrong with preserving all recording rules forever, even if for the sake of keeping table sizes down we archive them to oldrecord (just like we do for recording metadata) |
| [15:27:30] | stuartm: | if 're-record' is chosen and the old rule no longer exists in 'record' then we resurrect it from 'oldrecord' (copying it's guts and setting a this episode filter if it's a 'record all' rule) |
| [15:29:20] | sphery: | if moved to a separate table, that seems reasonable, though I don't know if there are things that we'd have to consider ( gigem would have to weigh in on that) |
| [15:42:14] | stichnot (stichnot!~stichnot@207.198.105.22) has joined #mythtv | |
| [15:42:14] | stichnot (stichnot!~stichnot@207.198.105.22) has quit (Changing host) | |
| [15:42:14] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [15:43:07] | gigem: | In principle, an oldrecord table sounds reasonable, but I know there would be some devils in the details. For example, I think we save the parent recordid in recorded when an override recording is made. That's so the recording gets tied to the parent when max-episodes is used. The consequence is that "delete and re-record" for an recording made from an override rule wouldn't know the actual rule that was |
| [15:43:09] | gigem: | used. That wouldn't bother me, but it might some. |
| [15:44:31] | stuartm: | the mheg breakage doesn't seem to be in the freemheg code, reverted that back to the pre2 tag which was created 10 months ago and it's still broken |
| [15:46:59] | gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has joined #mythtv | |
| [15:49:16] | stuarta: | stuartm: what breakage do you observe? |
| [15:50:26] | stuartm: | stuarta: it's just not loading, -v mheg shows it gives up trying to boot, there's no 'red button' logo displayed |
| [15:51:24] | stuarta: | is it receiving the mheg stream? |
| [15:52:53] | stuartm: | nothing from -v mheg,dsmcc --loglevel debug to suggest that anything is there (although it's definitely there in these old samples) |
| [15:53:05] | stuartm: | currently looking through the changelog for the dsmcc code |
| [15:55:49] | stuartm: | the only recent commit there was https://github.com/MythTV/mythtv/commit/9f900 . . . f847f788f4ee |
| [15:59:35] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 245 seconds) | |
| [16:00:06] | stuarta: | stuartm: run ffmpeg -i <file> on the livetv recording and see what streams it spits out |
| [16:02:02] | stuartm: | heh, all 'unknown' aside from video, audio and subtitle streams |
| [16:02:16] | stuarta: | pastebin it? |
| [16:02:21] | stuartm: | which is obviously a problem, used to correctly identify mheg |
| [16:04:23] | stuartm: | this is from mythffmpeg which is more informative than ffmpeg since it shows the codec id – http://pastebin.com/6Ribdzd1 |
| [16:05:15] | stuartm: | same result on the older sample |
| [16:09:26] | stuarta: | well there isn't a codec to handle dsmcc |
| [16:10:48] | stuartm: | AV_CODEC_ID_DSMCC_B |
| [16:12:20] | stuarta: | it should identify the streams as that, and then i'd be happy |
| [16:13:22] | stuartm: | yeah, it used to, I think one of the ffmpeg resyncs broke it |
| [16:13:44] | stuarta: | oh joy, that'll be fun to unbreak |
| [16:15:01] | stuartm: | going to start bisecting those made in the last six months :) |
| [16:15:58] | bergqvistjl (bergqvistjl!~John@79-67-250-255.dynamic.dsl.as9105.com) has joined #mythtv | |
| [16:16:04] | stuartm: | only because I'm pretty sure it was working earlier this year when I tested the iplayer stuff |
| [16:17:30] | bergqvistjl: | Hi, i've altered the Mythweb default EPG colours (and categories list) to be more appropriate to UK Freeview users using either EIT or XMLTV/Atlas. I was wondering how I'd get it submitted to Mythweb itself? |
| [16:17:40] | natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has joined #mythtv | |
| [16:17:47] | stuarta: | bergqvistjl: raise a ticket in trac |
| [16:17:54] | stuarta: | code.mythtv.org/trac |
| [16:18:04] | bergqvistjl: | Most of what i've done is just remove the individual genres/categories for films (Like Action, Western etc.) as that info isn't contained in EIT or XMLTV, it just says "Film" |
| [16:18:05] | bergqvistjl: | OK thanks |
| [16:18:51] | stuartm: | once I get it working again (if), then I'll create a unit test for codec identification |
| [16:20:02] | stuarta: | stuartm: \o/ |
| [16:22:12] | stuartm: | not sure what that would involve if I use the existing qt framework, but I'll give it a go |
| [16:23:02] | rsiebert_ (rsiebert_!~quassel@g226063211.adsl.alicedsl.de) has joined #mythtv | |
| [16:23:46] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [16:25:26] | rsiebert (rsiebert!~quassel@g225052019.adsl.alicedsl.de) has quit (Ping timeout: 240 seconds) | |
| [16:27:29] | bergqvistjl: | ok submitted: http://code.mythtv.org/trac/ticket/11827 |
| [16:36:58] | stichnot (stichnot!~stichnot@216.239.45.84) has joined #mythtv | |
| [16:36:58] | stichnot (stichnot!~stichnot@216.239.45.84) has quit (Changing host) | |
| [16:36:58] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [16:39:12] | stuartm: | heh, parcel being sent to me made it 330+ miles from Utrecht to Barking via Brussels in 12 hours, arriving there at 7:48am today, but they can't manage to deliver it the last 118 miles to my door before Monday |
| [16:40:08] | knightr: | bergqvistjl, we can't start having "translations" per provider like this and if there's a problem with the current category file you should get in touch with the English GB translator, Nick Morrott |
| [16:40:52] | knightr: | (which is listed here http://www.mythtv.org/wiki/Translation) |
| [16:51:18] | peper03: | stuartm: Still catching up on the logs, but Red Button works on 0.26-fixes. |
| [16:55:56] | jpabq: | gigem: I have tested the scenario you described. That patch still works. It works because of the way you setup the local->UTC management in that routine. The ambiguity you talked about is removed because you always do the conversion based on the original recording date. |
| [16:57:53] | jpabq: | I believe you were also concerned about repeating the wrong hour, but that is also not a problem. When the time-change (which results in an extra hour) happens, it is always the *previous* hour which is repeated. |
| [17:02:09] | bergqvistjl: | That's fine, i'll get in touch with Nick. |
| [17:06:24] | stuartm: | peper03: thanks |
| [17:07:48] | bergqvistjl: | Does anyone know where/how I can get hold of Mick Morrot? |
| [17:07:51] | bergqvistjl: | *Morrott? |
| [17:08:02] | knightr: | See the url I gave at 12:40 |
| [17:08:13] | knightr: | or in the ticket... |
| [17:08:49] | knightr: | As I said in the ticket if you see that none of the current categories are suitable we could add new categories everybody could use. I am not sure how synchro the categories are between the .cat files and the categories.xml file used in mythfrontend |
| [17:09:53] | knightr: | (so it might be best to check what mythfrontend currently uses as categories if you need to add new ones...) |
| [17:10:10] | Jordack (Jordack!~Jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv | |
| [17:10:50] | bergqvistjl: | I was on about Mythweb only, for now, as from the looks of things the EPG categories used in Frontend tend to vary from theme to theme. |
| [17:11:16] | stuartm: | peper03: can you run mythffmpeg -i against a livetv recording of a channel with red button? I'd like to be sure that it was correctly identifying the streams in 0.26 |
| [17:11:50] | knightr: | bergqvistjl, yep, some themes do provide that file unfortunately which is making it harder to maintain. We'll try to address this post 0.27... |
| [17:11:57] | bergqvistjl: | yeah. |
| [17:12:27] | knightr: | but if you need to add categories to MythWeb it would be a good place to start looking for categories you could add... |
| [17:13:08] | knightr: | (so that both the frontend and MythWeb categories would be more in sync with each other...) |
| [17:13:21] | bergqvistjl: | I've already done it, i'd just like approval to submit. But I see what you mean re. Mythweb and frontend syncing |
| [17:13:42] | bergqvistjl: | but right now it is mythweb only |
| [17:15:07] | stuartm: | peper03, stuarta: think I've found the issue |
| [17:16:34] | knightr: | bergqvistjl, for now it's best to do it for MythWeb only, we need to address the issue of the frontend categories file being provided by the themes which makes in very difficult to maintain... |
| [17:16:41] | bergqvistjl: | yes. |
| [17:17:17] | stuartm: | might not get a chance to try it out tonight though, I'm supposed to be going somewhere and recompiling ffmpeg takes an age on this machine |
| [17:17:48] | bergqvistjl: | but IMO the default GB colours and categories are the same as the US ones. |
| [17:18:06] | bergqvistjl: | and half the categories there don't apply to the GB guide data i've been getting, which was why i changed it |
| [17:19:56] | knightr: | I am sure you could remap some to suitable replacements (that's why we have regular expressions to do the matching) and if none of the categories there are suitable there's always the possibilit to add news ones... |
| [17:21:19] | knightr: | The translators in other non-US countries were able to remap their local categories to the ones currently supported but I am sure they would benefit from new categories as well... |
| [17:21:20] | bergqvistjl: | right, i've sent him an email. |
| [17:21:46] | knightr: | thank you! |
| [17:21:56] | bergqvistjl: | Yeah, well there was a whole swathe of redundant categories (mainly film genres) which were never used in my EIT/XMLTV guide data, so i removed them and merged some others |
| [17:23:15] | knightr: | they are used elsewhere so we can't remove them but, like I said, if adding new categories is needed I don't think it would be a problem... |
| [17:23:42] | bergqvistjl: | for example, in Mythweb "Interests" is grouped under "Education", now i've regrouped that to "Lifestyle" |
| [17:23:53] | bergqvistjl: | and renamed lifestyle to "Lifestyle and Interests" |
| [17:25:23] | bergqvistjl: | and as a result IMO, the guide looks much more consistent. |
| [17:27:58] | peper03: | stuartm: Yes, master is not identifying the streams (http://pastebin.com/ewkKqrbg if it still helps). If you have a patch, I'm happy to try it out. |
| [17:29:38] | bergqvistjl: | Old Categories: http://i.imgur.com/s3qh88t.png New Categories: http://i.imgur.com/IVMK57B.png Mine is much more slimmed down. |
| [17:31:22] | bergqvistjl: | For example, it would group "Reality" into the "Comedy" group which isn't strictly true. So i moved it into a new group called "Entertainment" |
| [17:31:42] | bergqvistjl: | which a lot of other programs were listed under in their own right |
| [17:35:05] | knightr: | if you can find a list of categories which would need to be added ping me here (or send me an email at nriendeau (at) mythtv.org) and I will get the translators' input as well about those and see what we can do.. |
| [17:36:11] | knightr: | It would be best for now to add and not necessarilly regrouped and we need to make sure these are consistent with what's in the frontend |
| [17:36:55] | knightr: | (and since we have some problems maitaining the one in the frontend regrouping them would best be avoided for now...) |
| [17:38:31] | bergqvistjl: | Well im focusing on MythWeb for now |
| [17:38:34] | bergqvistjl: | i'll see what Nick Says |
| [17:42:31] | stuartm: | peper03: thanks for checking, that is helpful, just a few seconds away from being able to test this patch myself and then I really have to get going :) |
| [17:43:54] | knightr: | bergqvistjl, anyway there's enough control in the cat files to do some minor regrouping since the translators have control over what is actually displayed for each category and how they are parsed... |
| [17:44:03] | bergqvistjl: | Yeah |
| [17:46:01] | bergqvistjl: | Would be nice if the colours for the categories were also contained in the .cat file, that way I wouldn't need to create an entirely new theme, but what the heck. |
| [17:46:08] | stuartm: | ok, fix wasn't enough on it's own – will look at it again tomorrow |
| [17:46:26] | stuartm: | Scheduled 999 items in 1.1 = 0.16 match + 0.09 check + 0.81 place |
| [17:46:29] | stuartm: | so close |
| [17:47:49] | knightr: | stuartm, do you think we'll have another RC or the next cut is the release? |
| [17:47:58] | knightr: | s/or/or if |
| [17:50:37] | knightr: | bergqvistjl, no need to create a new theme, we just need to add categories to the existing ones. Keep in mind that it must work for multiple languages and locations though so we have to do it in a matter that works for everybody... |
| [17:51:01] | bergqvistjl: | ah, but i've modified a couple of the colours for the existing ones though... |
| [17:53:21] | knightr: | bergqvistjl, we can add new colors for new categories but changing colors for the existing categories should be avoided... Maybe it improves the "experience" for one locale but it might very well worsen it for others... |
| [17:53:28] | bergqvistjl: | True... |
| [17:55:16] | knightr: | ttyl, gotta go, I will be back later... |
| [17:55:17] | bergqvistjl: | OK, actually i've only changed a single category's colours. I made education the same colour as HowTo, and renamed HowTo to Education (in the translation) |
| [17:55:47] | knightr: | LOL, I can see why, they are somewhat related... :-) |
| [17:56:14] | bergqvistjl: | That's the old categories: http://i.imgur.com/s3qh88t.png Those are the new ones: http://i.imgur.com/IVMK57B.png So you can see the changes i've made there :) |
| [17:57:17] | knightr: | yep... |
| [17:57:41] | bergqvistjl: | So they're not major really |
| [18:00:30] | bergqvistjl: | I also split science and nature up, but that's only cos i'm fed up of seeing Horizon in the same category as Springwatch xD |
| [18:01:09] | robink_ is now known as robink | |
| [18:12:05] | bergqvistjl (bergqvistjl!~John@79-67-250-255.dynamic.dsl.as9105.com) has quit (Quit: Leaving.) | |
| [18:20:06] | exoon (exoon!~exoon@p4FD4066E.dip0.t-ipconnect.de) has joined #mythtv | |
| [18:20:34] | exoon (exoon!~exoon@p4FD4066E.dip0.t-ipconnect.de) has quit (Read error: Connection reset by peer) | |
| [18:26:03] | Tobbe5178: | short question, am i right in assuming 0.27 still depends on old libcec for cec to work? |
| [18:26:24] | Tobbe5178: | that is, libcec < major version 2 |
| [18:31:47] | knightr: | Tobbe5178, AFAIK, yes, I haven't seen any patches for that get committed... |
| [18:32:09] | Tobbe5178: | ok, maybe i forgot to submitt a patch for it too... |
| [18:32:27] | Tobbe5178: | i have one for 0.26 that updates the cec support to work with libcec v2 |
| [18:33:00] | Tobbe5178: | i remember discussing it too somewere but i dont remeber the exact details |
| [18:33:12] | knightr: | Tobbe5178, there's already one on Trac (our bug tracker) and I believe somebody had posted one on the mailing list as well... |
| [18:33:54] | Tobbe5178: | i think someone else was working on cec too |
| [18:33:56] | knightr: | both claimed to make it work with v2 but one of them did other things as well IIRC... |
| [18:34:47] | Tobbe5178: | thats where i saw it, looks like i started that mail thread :) |
| [18:35:30] | Tobbe5178: | 3 step memory, 3 steps and its gone :) |
| [18:35:43] | knightr: | ROTFL |
| [18:37:37] | Tobbe5178: | just checking what local patches i might need to move over to 0.27 when i decide to upgrade |
| [18:45:50] | dgeary2 (dgeary2!~debian@pa49-187-80-132.pa.nsw.optusnet.com.au) has joined #mythtv | |
| [19:01:08] | gigem: | jpabq: I don't think you understand. It works for your test because when converting local to UTC on Linux, Qt always uses the earlier time when it is ambiguous. It won't work on Windows where Qt always uses the later time and it will only work some of the time on OS X, where, AIUI, Qt uses either time based on some magic criteria. |
| [19:01:42] | gigem: | stuartm: Might that parcel be your new Nook? I'm thinking seriously about getting an HD+ to play around with. |
| [19:10:59] | jpabq: | gigem: What is ambiguous? If I create a manual daily recording rule for "2013-09–04 01:00:00" local time that always translates to "2013-09–04 07:00:00" UTC in the DB. When it comes time to handle that recording rule on the day of the time change, it convert "2013-09–04 07:00:00" UTC back to local time which is always 1am. |
| [19:11:11] | jpabq: | If I create a manual daily recording rule for "2013-12–12 01:00:00" local time that always translates to "2013-12–12 08:00:00" UTC in the DB. When it comes time to handle that recording rule on the day of the time change, it convert "2013-12–12 08:00:00" UTC back to local time which is always 1am. |
| [19:11:22] | jpabq: | Since either way it translates back to 1am local time, there is no ambiguity. |
| [19:13:26] | jpabq: | Where local time is Mountain for that example. |
| [19:18:45] | gigem: | jpabq: You're missing the fact the date math at the bottom of the "while (progcount--)" loop is done in local time and then converted to UTC. In your daily record example, it will eventually hit "2013-11–03 01:00:00" and convert that to UTC. It is that conversion which is ambiguous. |
| [19:20:00] | jpabq: | Okay, but as long as it is consistent and not arbitrary, it should still work. |
| [19:21:16] | gigem: | No, it won't work. Your patch will only work on Linux. |
| [19:21:33] | jpabq: | I can build this on my mac and try it. |
| [19:22:36] | gigem: | Be sure to test several times. The web page I read last night said the Mac version of Qt changes its behavior around the 48 minute after hour mark. |
| [19:25:23] | dgeary2_ (dgeary2_!~debian@pa49-187-92-160.pa.nsw.optusnet.com.au) has joined #mythtv | |
| [19:26:05] | gigem: | I still don't like the two programs bit. So it wastes 1 hour of disk space for something that might happen once a year. Big deal. |
| [19:26:44] | jpabq: | By that argument, we should consider 'unidentified' episodes as dupes. |
| [19:28:14] | dgeary2 (dgeary2!~debian@pa49-187-80-132.pa.nsw.optusnet.com.au) has quit (Ping timeout: 240 seconds) | |
| [19:50:46] | danielk221 (danielk221!~danielk22@exchange.wgen.net) has quit (Ping timeout: 240 seconds) | |
| [19:54:02] | gigem: | How so? Personally, I find both the one longer program and two normalength program solutions ugly to a non-problem. Either one will cause confused users to question why is MythTV doing it? That is, if they ever even hit this really, really, really obscure case. You seem bent on solving this intellectual exercise, however, so I'm trying to work with you. Of the two ugly solutions, I'll state one more time |
| [19:54:04] | gigem: | that I prefer the one longer program. |
| [20:13:24] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!) | |
| [20:34:45] | natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has quit (Ping timeout: 248 seconds) | |
| [20:37:01] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [21:04:15] | Anssi (Anssi!hannulaa@mandriva/developer/anssi) has quit (Ping timeout: 260 seconds) | |
| [21:05:38] | Anssi (Anssi!hannulaa@mandriva/developer/anssi) has joined #mythtv | |
| [21:23:14] | stuartm: | gigem: yeah, that's the parcel |
| [21:25:33] | jpabq: | gigem: sorry, I misread what you said there. |
| [21:26:24] | stuartm: | I wavered between the HD and the HD+, but decided I'd get more use from the HD because it's a little more portable – though if I like the HD I may still get an HD+ assuming it's still available at that time |
| [21:30:44] | stuartm: | knightr: well that depends on whether I can fix this mheg regression before Monday, it's a blocker as far as I'm concerned, but otherwise there have been very few fixes and even fewer tickets submitted against the first RC so at this stage a second RC is looking unnecessary |
| [21:31:59] | stuartm: | the weekend will be interesting, that's when most people will have the time to try out RC1 and when we'll get any bug reports (if there are unknown bugs to be found) |
| [21:32:25] | SteveGoodey (SteveGoodey!~steve@host109-158-215-102.range109-158.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [21:45:51] | gigem: | jpabq: No problem, and see your email. |
| [21:48:38] | gigem: | stuartm: Cool. Let me know how you like it. |
| [21:55:51] | Jordack (Jordack!~Jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit (Quit: You will never know how you look in the eyes of other people.) | |
| [22:46:56] | jedix (jedix!~jedix@198-84-204-50.cpe.teksavvy.com) has joined #mythtv | |
| [22:47:07] | jedix (jedix!~jedix@198-84-204-50.cpe.teksavvy.com) has left #mythtv () | |
| [23:03:08] | knightr: | stuartm, thank you! if we had had another RC for sure I would have checked with the translator if we could do an exception to the string freeze (since it would have given everybody one more week...) and fix the string you wanted to fix and 2 or 3 other strings as well... |
| [23:04:06] | knightr: | I think I need to check more closely what I did to make my frontend freeze yesterday, I got both freezes and a crash with a checkout that wasn't very old... |
| [23:04:44] | knightr: | (maybe the problem I had has been fixed, I need to update to the latest master to know for sure...) |
| [23:13:38] | stuartm: | instead of a second RC, we could just stretch out this RC for another week, there's little point in a second RC if nothing has really changed since the first one but there are still outstanding bugs that could use some attention before a release |
| [23:16:23] | Chutt (Chutt!~ijr@cpe-76-190-199-73.neo.res.rr.com) has quit (Read error: Connection reset by peer) | |
| [23:17:56] | paul-h (paul-h!~Paul@2.219.20.71) has quit (Quit: Konversation terminated!) | |
| [23:18:39] | Chutt (Chutt!~ijr@cpe-76-190-199-73.neo.res.rr.com) has joined #mythtv | |
| [23:20:45] | stuartm: | stuarta: turns out the identification of dsmcc streams wasn't broken, just the presentation of a user friendly string in the logs, so I'm back to square one |
| [23:34:56] | wagnerrp_: | knightr: mythscreenwizard is supposed to refuse to run when you have mythtv configured to run in a window |
| [23:35:28] | wagnerrp_ is now known as wagnerrp | |
| [23:35:42] | wagnerrp: | although i'm not aware if we give any notification to the user why it does not run |
| [23:35:55] | wagnerrp: | as it runs as an external application and terminates immediately |
| [23:44:36] | stichnot: | stuartm: I think the answer is no, but for the guidegrid, is there any way to override the flags Qt::AlignLeft | Qt::AlignTop | Qt::TextWordWrap ? |
| [23:44:49] | IReboot (IReboot!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has quit (Quit: Ex-Chat) | |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.
