| Thursday, October 20th, 2011, 00:13 UTC | ||
| [00:13:12] | sphery: | davide: TTBOMK, we don't have a way. Closest approach I can think of is to delete any capture cards to which the video source is connected (or at least delete the input connections), then you'd have to run mythfilldatabase specifically for the sources that remain, using --sourceid (I think that means 2 separate runs of mfdb)... |
| [00:13:20] | taylorr (taylorr!~taylorr@cpe-173-095-145-027.nc.res.rr.com) has joined #mythtv | |
| [00:13:20] | taylorr (taylorr!~taylorr@unaffiliated/elmojo) has joined #mythtv | |
| [00:13:20] | taylorr (taylorr!~taylorr@cpe-173-095-145-027.nc.res.rr.com) has quit (Changing host) | |
| [00:14:34] | somethinginteres (somethinginteres!~something@ppp29D1.dsl.pacific.net.au) has joined #mythtv | |
| [00:15:18] | sphery: | davide: I've been thinking of breaking channum/callsign type information out of channel into a separate table that can be ref'ed from channel just for this (since a lot of users seem to want old recordings to have old channel info when they switch providers). If you have thoughts/preferences for an approach, please let me know. I might be able to work it when I start working the recordedfile changes (planned for shortly after 0.25 release) |
| [00:18:57] | somethinginteres: | re-installed mythtv from a db backup. Everything working fine, expect: I have issues getting clear reception on ABC, a channel that was previously crystal clear. Please see: http://i.imgur.com/tGXuG.jpg |
| [00:20:03] | sphery: | somethinginteres: /topic (you want #mythtv-users ) |
| [00:20:41] | Beirdo: | muuuch better |
| [00:20:46] | somethinginteres: | sphery: oops. Thanks! |
| [00:25:01] | kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has quit (Quit: kormoc) | |
| [00:36:41] | taylorr: | danielk22, jpabq-: do we set v4l picture controls when recording with an hd-pvr? |
| [00:42:11] | somethinginteres (somethinginteres!~something@ppp29D1.dsl.pacific.net.au) has left #mythtv ("Leaving") | |
| [00:42:23] | sphery: | knightr: stuartm would be the one to approve or disapprove this approach, but, IMHO, we'd be best off just replacing all the date formats we have with translated/translatable ones and/or allowing users to edit them. I know there are some annoying issues with them, even in English--such as no short date formats with years. Having it translatable would allow translators--or even "advanced" users to edit the formats, even if we don't allow users ... |
| [00:42:29] | sphery: | ... to specify values directly in the UI. |
| [00:48:09] | 17WAAF6BR: | taylorr, I believe it tries, but with the "good" firmware, it is effectively a NOOP. |
| [00:48:28] | jpabq- (jpabq-!~jpabq@174-28-167-122.albq.qwest.net) has quit (Quit: ZNC - http://znc.sourceforge.net) | |
| [00:48:28] | 17WAAF6BR (17WAAF6BR!~jpabq@mythtv/developer/jpabq) has quit (Quit: ZNC - http://znc.sourceforge.net) | |
| [00:48:52] | jpabq (jpabq!~jpabq@mythtv/developer/jpabq) has joined #mythtv | |
| [00:50:04] | jpabq- (jpabq-!~jpabq@174-28-167-122.albq.qwest.net) has joined #mythtv | |
| [00:53:28] | jpabq: | taylorr, take a look at libs/libmythtv/v4lchannel.cpp |
| [00:54:42] | knightr: | sphery, Thanks! I do want to make sure it's not actually handled by the Qt/C librairies/OS though... It looks like it might not (I think we use QDates there and it supports adding characters which are copied verbatim in the output) but I want to make sure... I think our best bet would be to let them choose between the current ones or choose to "custom" and let them enter their own pattern... |
| [00:56:01] | taylorr: | jpabq: do we always set the picture control each time we tune a channel for recording? |
| [00:56:07] | knightr: | Funny thing is I'm pretty sure that for a new installation (or one when the user choose to reset the settings) the locale files do currently permit to choose a setting which is not in the lists so this could be a possible workaround... |
| [00:56:21] | knightr: | (not a good one but a workaround nonetheless...) |
| [00:56:24] | jpabq: | taylorr, yes, it is a per-channel config |
| [00:56:42] | taylorr: | do you know what the defaults are? |
| [00:58:17] | taylorr: | I see now... they default to 32768 |
| [00:59:13] | jpabq: | You are faster than I am. I was just about to report that. |
| [00:59:31] | knightr: | s/to// |
| [00:59:37] | taylorr: | jpabq: can you dump your hdpvr picture control values using v4l-info or v4l-ctl |
| [00:59:58] | taylorr: | brightness seems a little different on my hdpvrs |
| [01:01:00] | jpabq: | taylorr, want to save me some time, and tell me exactly what v4l-ctl options to use? |
| [01:02:03] | taylorr: | I used v4l-info /dev/video1 |
| [01:02:12] | taylorr: | I don't even know where to get v4l-ctl |
| [01:04:45] | jpabq: | brightness (int) : min=0 max=255 step=1 default=134 value=134 flags=slider |
| [01:05:03] | jpabq: | contrast (int) : min=0 max=255 step=1 default=128 value=128 flags=slider |
| [01:05:21] | jpabq: | The rest are the same as contrast |
| [01:05:34] | taylorr: | they are totally wrong |
| [01:05:54] | davide (davide!~david@host70.16.intrusion.com) has quit (Remote host closed the connection) | |
| [01:06:15] | taylorr: | jpabq: the brightness is exactly the default in the driver (134 = 0x86) |
| [01:06:18] | davide (davide!~david@host70.16.intrusion.com) has joined #mythtv | |
| [01:06:22] | taylorr: | and the others are the same as in the driver too |
| [01:06:35] | taylorr: | so it's like mythtv isn't actually setting them |
| [01:06:59] | jpabq: | taylorr, I have not tried to tell myth to set them. Would you like me to? |
| [01:07:25] | jpabq: | Oops. Can't now. both my HD-PVRs are recording. |
| [01:08:57] | taylorr: | jpabq: yes, when you can... it'd be cool to see if they make a change or not |
| [01:09:48] | jpabq: | Is VIDIOC_S_CTRL wired in the driver? It looks like that is the ioctl that myth is trying to use to set it. |
| [01:11:55] | jpabq: | taylorr, it looks like Myth is using a formula to get the value: (0x10000 + (int)(dfl * old_range) – 32768) & 0xFFFF; |
| [01:12:37] | taylorr: | but still, the values match the values defaulted in the driver |
| [01:13:07] | danielk22: | taylorr: Pretty sure we set it for each channel, there are per card video controls and also per channel video controls. The idea is that you adjust the per card to get most channels right, and then adjust per channel to adjust for the badly controlled channels, like the public access channels. |
| [01:13:42] | iamlindoro: | What about just not supporting picture controls, period, for the HD-PVR until the driver situation gets sorted out? |
| [01:13:49] | taylorr: | danielk22: do you have to enable picture controls for a specific channel for it to work? |
| [01:14:02] | taylorr: | iamlindoro: I'm in favor of that |
| [01:14:46] | danielk22: | taylorr: it's always on.. but the defaults are to leave the settings centered. |
| [01:15:04] | taylorr: | ok... those defautls will not work with the hdpvr... period |
| [01:15:21] | jpabq: | danielk22, taylorr's point, is that myth is (in theory) setting brightness, contrast, saturation, hue to 32768, but if you actually query the HD-PVR driver, it is returning 134 for brightness and 128 for everything else. Which kinda indicates that that ioctl is not working for the HD-PVR> |
| [01:16:04] | jpabq: | even if 32768 is getting converted to 128, why does the driver report 134 for brightness. |
| [01:16:12] | taylorr: | iamlindoro: where is that page with the info on the hdpvr you sent earlier? |
| [01:16:31] | taylorr: | jpabq: 134 is 0x86 which is what the driver has in it's code |
| [01:16:45] | iamlindoro: | taylorr: HD-PVR article on the myth wiki |
| [01:16:48] | iamlindoro: | discussion page |
| [01:16:55] | taylorr: | ah... discussions |
| [01:17:08] | danielk22: | *shrug* we should probably disable these settings for the HD-PVR until the problem is worked out. Especially since it seems to have something to do with the firmware revision. |
| [01:18:20] | danielk22: | taylorr: in V4LChannel::Open() we query the driver name, it should be fairly simple to disable picture controls when this == "hdpvr" |
| [01:18:56] | taylorr: | danielk22: first we need to manually set the controls for 0x15 (old) and 0x17 (new) and see the differences |
| [01:19:11] | taylorr: | my guess is that 0x15 doesn't support picture controls and 0x17 does |
| [01:19:40] | taylorr: | unless those values that are being used were correct for 0x15 |
| [01:19:44] | danielk22: | dunno, it would be the driver that tells myth if they are enabled or not. |
| [01:20:30] | danielk22: | We use the same code for all Video4Linux cards... |
| [01:21:14] | taylorr: | yep, got it fixed for 0x17 |
| [01:22:47] | taylorr: | SWEET! looks like 0x15 totally ignores picture controls |
| [01:23:05] | danielk22: | Looking at set_v4l2_attribute_value it looks like we do normalize from 0..65535 to whatever the card's range is. |
| [01:26:01] | danielk22: | It looks like there is a typo in get_v4l2_attribute_value() 65525 near the bottom should probably be 65535. |
| [01:26:48] | danielk22: | (shouldn't cause any real problem though.) |
| [01:27:25] | taylorr: | danielk22: we should be fine for the hd-pvr – definitely should not allow any per channel controls though |
| [01:27:54] | danielk22: | taylorr: why? |
| [01:28:29] | taylorr: | because the values for the per channel setup are wrong |
| [01:28:41] | taylorr: | they will cause a terrible picture for the hd-pvr |
| [01:28:57] | danielk22: | taylorr: shouldn't we just fix that :) |
| [01:29:19] | taylorr: | I dunno |
| [01:30:12] | danielk22: | The default per recorder and per channel settings are supposed to be no-modify, if that is not the case anymore there is a bug somewhere.. |
| [01:30:31] | taylorr: | we have per recorder? |
| [01:31:28] | danielk22: | yep per channel and per capturecard; |
| [01:32:06] | taylorr: | where is the per capturecard stored? |
| [01:32:31] | danielk22: | in the capturecard table :) |
| [01:34:13] | taylorr: | they are all set to zero for hdpvr capture cards |
| [01:34:14] | danielk22: | Those are added together to get the final value. The capturecard value can adjust for any recorder peculiarities (such as the default brightness being at 60% rather than 50%).. |
| [01:34:24] | taylorr: | which is not being applied obviously |
| [01:34:57] | danielk22: | taylorr: really? when you change the capturecard values it doesn't have any effect? |
| [01:34:57] | taylorr: | ah... so they are added together |
| [01:35:40] | taylorr: | I'm not... all I'm saying is that the values that are set in the driver do not exist anywhere in the mythtv code/settings |
| [01:36:06] | taylorr: | so these values are getting set somewhere else |
| [01:36:47] | taylorr: | personally I'd like to see us detect hdpvr and set the working values and make sure we don't apply per channel or per recorder settings |
| [01:39:38] | danielk22: | taylorr: The proper way to handle this would be to set the default capturecard contrast,brightness,colour,hue values for the hd-pvr so that we set the default values by default. This is assuming the picture controls really do work with that firmware. |
| [01:40:11] | taylorr: | set where? in the database? |
| [01:40:16] | danielk22: | taylorr: yes |
| [01:40:23] | taylorr: | gotta reboot |
| [01:40:40] | taylorr (taylorr!~taylorr@unaffiliated/elmojo) has quit (Remote host closed the connection) | |
| [01:42:27] | taylorr (taylorr!~taylorr@cpe-173-095-145-027.nc.res.rr.com) has joined #mythtv | |
| [01:42:27] | taylorr (taylorr!~taylorr@cpe-173-095-145-027.nc.res.rr.com) has quit (Changing host) | |
| [01:42:27] | taylorr (taylorr!~taylorr@unaffiliated/elmojo) has joined #mythtv | |
| [01:42:34] | taylorr: | back |
| [01:42:57] | kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has joined #mythtv | |
| [01:43:30] | taylorr: | jpabq: any ideas how those values are getting set in the driver? |
| [01:44:53] | jpabq: | In the driver? I have not looked at the driver, but it looks like myth is using the VIDIOC_S_CTRL ioctl |
| [01:45:14] | taylorr: | jpabq: any ideas where the values it is using are coming from? |
| [01:45:40] | taylorr: | wondering if Janne put the same values in the mythtv source somewhere that are the same as the driver |
| [01:46:37] | jpabq: | Myth always uses a range of 0 – 65535 and then scales to whatever the driver reports. The HD-PVR driver is reporting 0–255, so myth tries to scale 0–65535 into that range. |
| [01:46:59] | taylorr: | jpabq: so where are the values coming from? |
| [01:47:31] | taylorr: | they aren't coming from the per channel/recorder settings |
| [01:47:34] | jpabq: | The 0–65535 values? They are stored in the channel table in the database. |
| [01:48:25] | taylorr: | jpabq: they are all 32768... yet when you dump the picture controls in the driver brightness is different |
| [01:48:33] | taylorr: | so they can't be coming from the channel table |
| [01:49:14] | jpabq: | taylorr, my guess is that the HD-PVR driver is rejecting the value that myth is passing in that ioctl. |
| [01:49:57] | taylorr: | jpabq: I've made changes to the driver that should be working but they aren't |
| [01:50:02] | taylorr: | doing a clean compile now |
| [01:51:55] | taylorr: | jpabq: if you run this v4l2-ctl --set-ctrl brightness=0x80 --set-ctrl contrast=0x40 --set-ctrl hue=0xf --set-ctrl saturation=0x40 --set-ctrl sharpness=0x80 then 0x17 works great |
| [01:52:13] | jpabq: | TVRec::TuningNewRecorder calls channel->InitPictureAttributes() but I am not convinced that routine is doing the right thing. |
| [01:52:13] | taylorr: | for 0x15 you can set those values to anything you want and the picture doesn't change at all |
| [01:52:56] | jpabq: | on the other hand, set_v4l2_attribute_value in v4lchannel.cpp looks like it is. |
| [01:53:00] | taylorr: | jpabq: it'd be nice to get a fix in for myth and backport it so people can update their driver |
| [01:53:14] | taylorr: | s/driver/firmware/ |
| [01:53:20] | danielk22: | taylorr: why not instrument set_v4l2_attribute_value() and see what it is actually sending... |
| [01:53:34] | taylorr: | I'm working from the ground up :) |
| [01:54:18] | danielk22: | (: if v4l2-ctl seems to be working I think that's the next step :) |
| [01:54:34] | jpabq: | taylorr, does the driver need any modifications? |
| [01:54:38] | taylorr: | looking into the driver side first |
| [01:55:00] | jpabq: | If the driver is working, I can spend some time on the myth side of things, this weekend. |
| [01:55:28] | jpabq: | I have avoided 0x17 until now, but I can load it up on one of my HD-PVRs on Saturday. |
| [01:55:34] | taylorr: | the driver must work because v4l2-ctl works ;) |
| [01:56:06] | taylorr: | so I'm not crazy could you play with the picture controls on 0x15 and confirm they don't work |
| [01:56:22] | jpabq: | Or, I could get davide to send me his spare HD-PVR so I don't have to wait for a quiet recording day ;-) |
| [01:57:04] | jpabq: | taylorr, I know they don't work. The pict controls have never worked on the HD-PVR. I have never tried 0x17, though, so.... |
| [01:58:09] | taylorr: | jpabq: they work on 0x17 |
| [01:59:05] | jpabq: | Okay. I will play with it on Saturday. |
| [01:59:42] | danielk22: | taylorr: I got a user report sent to me maybe two weeks ago about funky colors with 0x17 that were fixed by going to an older firmware (presumably 0x15). So I don't think you are crazy. :) |
| [02:00:08] | cattelan is now known as cattelan_away | |
| [02:01:50] | jpabq: | taylorr, what values are you setting via v4l2-ctl that look good? |
| [02:01:58] | sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Quit: Ex-Chat) | |
| [02:02:13] | taylorr: | jpabq: any chance we are querying the values and then setting back what we query? |
| [02:02:35] | taylorr: | jpabq: v4l2-ctl --set-ctrl brightness=0x80 --set-ctrl contrast=0x40 --set-ctrl hue=0xf --set-ctrl saturation=0x40 --set-ctrl sharpness=0x80 |
| [02:03:19] | jpabq: | taylorr, TVRec::TuningNewRecorder calls channel->InitPictureAttributes(); I presume that sometime later, TVRec::ChangePictureAttribute calls channel->ChangePictureAttribute |
| [02:04:13] | jpabq: | taylorr, interesting. If those values look good, we may want to change the driver, such that those are the defaults. |
| [02:04:33] | taylorr: | jpabq: that's what I'm working on now |
| [02:04:57] | taylorr: | but since it might take forever for driver changes to make it's way to users we should probably get mythtv to setup them |
| [02:05:47] | jpabq: | I wonder if the range for hue is really 0–1E instead of 0-FF ? |
| [02:06:38] | taylorr: | jpabq: the firmware only accepts 0–1E |
| [02:07:05] | jpabq: | And Saturation range would be 0–1F ? |
| [02:07:18] | taylorr: | the other four are 0–256 |
| [02:07:44] | jpabq: | But 0x40 looks correct for saturation and contrast? |
| [02:07:52] | taylorr: | right |
| [02:07:59] | taylorr: | that's 64 |
| [02:08:34] | jpabq: | So 25% of the range, instead of 50% |
| [02:09:09] | taylorr: | let me check |
| [02:10:16] | taylorr: | yes the windows driver has a range of 0–255 for everything except hue |
| [02:10:30] | jpabq: | Okay |
| [02:10:38] | taylorr: | hue is represented by -30 – +30 |
| [02:11:09] | taylorr: | if you divide by 2 and add 15 you get 0–15 |
| [02:11:47] | taylorr: | oops I meant 0 – 1E |
| [02:12:23] | jpabq: | It would have been nice, if we could have just setup Myth to override the driver's reported range. Then we could have left the DB alone, and 32768 would have been converted into 50% of the range. |
| [02:13:27] | taylorr: | I still think we should just explicitly set the correct values in mythtv and disable any other type of adjustments |
| [02:13:59] | taylorr: | seriously, picture controls were totally broke in the firmware until now... I haven't heard anyone complain |
| [02:14:12] | jpabq: | Actually, I have, but it has been over a year. |
| [02:14:45] | taylorr: | most people wouldn't know how to set the controls anyway |
| [02:14:57] | taylorr: | I'm still not sure how hue would be handled |
| [02:15:30] | taylorr: | hue defaults to 0 which correlates to 0/2 + 15 = 0xF |
| [02:17:03] | jpabq: | I would expect the driver to report a HUE range of 0x0 – 0x15, with a default of 0x0F |
| [02:17:26] | taylorr: | I didn't see in the driver where it reported ranges? |
| [02:17:32] | jpabq: | Sorry, a range of 0x0 – 0x1F |
| [02:17:55] | jpabq: | It must be. How else would v4l2-ctl know what to say? |
| [02:18:11] | jpabq: | v4l2-ctl --device=/dev/hdpvr1 --list-ctrls |
| [02:18:15] | taylorr: | heh, that's true.. I didn't pay attention |
| [02:19:34] | taylorr: | jpabq: but in mythtv would would you set hue to so it translates into 0xF for the driver :) |
| [02:20:46] | jpabq: | In myth, for now, I would be tempted to override the hue range to be 0 – 0x1f. Then 32768 would translate into 0xf. |
| [02:22:18] | taylorr: | jpabq: yes, that sounds like a good idea |
| [02:28:06] | sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv | |
| [02:29:05] | taylorr: | jpabq: ok found the min/max values |
| [02:30:04] | jpabq: | Cool. Like you said, though, it will take months for that change to make it's way into the kernel. |
| [02:30:45] | taylorr: | jpabq: I need to sniff the usb bus again and make sure once we get above 128 on some of the controls that the driver goes beyond that |
| [02:31:09] | taylorr: | because you're right it makes sense that 0x40 is 50% |
| [02:31:40] | jpabq: | Okay. Been a while since I have needed to install a custom driver, but if you get this all worked out I will, so I can get myth working with it. |
| [02:32:01] | taylorr: | jpabq: but you don't need to update the driver :) |
| [02:32:16] | taylorr: | you can explicitly set the correct values in myth... right? |
| [02:32:23] | jpabq: | That is the plan |
| [02:32:40] | taylorr: | ah... I see what you mean... getting mythtv controls working properly |
| [02:33:08] | jpabq: | Let me know about those ranges. If they are 0–128, that would change my approach. |
| [02:33:13] | taylorr: | jpabq: so we want all the per channel 32768 to map to 50% in the driver |
| [02:33:24] | jpabq: | That would be nice. |
| [02:33:39] | taylorr: | yep, I'll check them either later tonight or the morning... we'll document them in MythTV and the driver |
| [02:34:19] | taylorr: | wait... I can check now... one sec |
| [02:34:29] | jpabq: | If the HD-PVR can really take 0–255 for contrast, though, then the myth "fix" will have to be different. I may have to just do what you suggest, and force it. |
| [02:57:28] | taylorr: | jpabq: I just checked and all are 0–255 except hue |
| [02:57:54] | taylorr: | I used WinTV7 to check the picture and sure enough they adjust through the entire range too |
| [02:58:20] | jpabq: | taylorr, okay. Well, in that case, if we want to continue to allow the user those controls, a DB change will be necessary. |
| [02:58:24] | taylorr: | I wonder why they are set to 25%... looks got to me though |
| [02:59:26] | jpabq: | I am not surprised that contrast is at 25%, but I am a little about saturation. |
| [03:00:29] | taylorr: | jpabq: when you upgrade to 0x17 just check them yourself and make sure I'm right |
| [03:01:07] | jpabq: | Actually, I am not sure a DB change will be possible. How would dbcheck know which channels are HD-PVR channels? |
| [03:01:29] | jpabq: | danielk22 ^^ |
| [03:01:30] | taylorr: | it wouldn't... we'll just have to do a translation |
| [03:03:53] | jpabq: | translate to what, though? By default, Myth sets those values to 50%. If the HD-PVR needs contrast and saturation set to 25% to look good, then 25% should be the default. I don't know if we can set the default to 25% just for the HD-PVR. |
| [03:07:35] | taylorr: | jpabq: it will have some limitation |
| [03:07:59] | taylorr: | we'll have to divide by 2 |
| [03:08:36] | taylorr: | which would artificially restrict the max from 255 to 127 |
| [03:08:44] | taylorr: | no one will no |
| [03:08:47] | taylorr: | know |
| [03:08:53] | jpabq: | :) |
| [03:09:12] | taylorr: | jpabq: ok, I got the driver situated... he's the weird part |
| [03:09:30] | taylorr: | when I load the driver it sets the controls to the correct values |
| [03:10:02] | taylorr: | and when mythbackend loads it leaves everything the same except hue which it subtracts by 1 |
| [03:10:13] | taylorr: | so default is 15 and myth sets it to 14 |
| [03:11:38] | jpabq: | taylorr, I may know why that is happening. Like danielk22 said, there is a typo. 65525 instead of 65535 |
| [03:12:02] | taylorr: | where is that typo? |
| [03:12:39] | taylorr: | ok... mythtv must be querying the driver for the default values and then applying them back |
| [03:13:06] | jpabq: | The typo is in v4lchannel.cpp |
| [03:14:23] | taylorr: | because until I changed the compiling now |
| [03:15:10] | jpabq: | It does not look like myth is trying to set sharpness. |
| [03:16:11] | taylorr: | but it sets the other 4? |
| [03:18:00] | taylorr: | jpabq: changing that value to 65535 didn't help |
| [03:18:07] | taylorr: | still changes it to 14 |
| [03:18:25] | jpabq: | Bummer. |
| [03:18:48] | jpabq: | Correct, myth is setting brightness, contrast, saturation and hue |
| [03:19:41] | jpabq: | taylorr, does the driver have a version #? |
| [03:20:21] | taylorr: | I don't think so |
| [03:20:36] | taylorr: | where does it set hue? |
| [03:23:46] | jpabq: | V4LChannel::InitPictureAttribute and V4LChannel::ChangePictureAttribute are where it is issuing the ioctls |
| [03:29:22] | taylorr: | jpabq: here is my driver changes -> http://mythtv.pastebin.ca/2091675 |
| [03:30:30] | jpabq: | Looks simple enough. So, those sleeps are not necessary? |
| [03:31:11] | taylorr: | jpabq: those are some upstream changes I backported |
| [03:31:16] | taylorr: | not sure if they hurt or help |
| [03:31:22] | jpabq: | okay |
| [03:44:07] | taylorr: | jpabq: ChangePictureAttribute would only be called if you were changing the value during playback... right? |
| [03:47:34] | jpabq: | That sounds right. |
| [03:47:54] | jpabq: | taylorr, in theory, something like this should fix us up: http://mythtv.pastebin.ca/2091679 |
| [03:49:14] | jpabq: | I am a little concerned by some of the things you have said, though. if you manually setting the hue to a valid value *in* myth is not working, then there is a bug in the current code, somewhere. |
| [03:50:58] | taylorr: | I'm not manually doing anything |
| [03:51:35] | taylorr: | just starting mythtv and starting a recording and it changes hue from 15 to 14 everytime |
| [03:51:44] | taylorr: | I like your patch |
| [03:52:22] | jpabq: | taylorr, I am actually not sure what driver_name will equal for the HD-PVR. That was a guess. |
| [03:52:47] | taylorr: | I thought that we used "hdpvr" elsewhere |
| [03:53:19] | jpabq: | true. We use hdpvr in mpegrecorder. That is probably it. |
| [03:53:22] | taylorr: | yeah, in mpegrecorder |
| [03:56:49] | taylorr: | jpabq: your "else" should have qctrl.maximum = 0xff not 0x7f |
| [03:57:36] | jpabq: | Really? |
| [03:58:45] | jpabq: | I though brightness was 0xff and the other two where 7f? |
| [03:59:18] | jpabq: | It is not handling sharpness |
| [04:02:39] | taylorr: | the maximum is 0xff for everything but hue |
| [04:03:11] | taylorr: | ah, but if you set the range to 127 then it will work with the current values |
| [04:03:26] | jpabq: | Hey, it was your idea! |
| [04:04:25] | joe__ (joe__!~jmk@64.73.32.135) has joined #mythtv | |
| [04:04:50] | jpabq: | I like it, because it gives the user *some* control. The other (easy) option is to take all control away. |
| [04:05:19] | jams (jams!~jams@cpe-184-58-217-97.wi.res.rr.com) has quit (Read error: Operation timed out) | |
| [04:05:19] | _charly_ (_charly_!kroseneg@sunrise.schmidham.net) has quit (Read error: Operation timed out) | |
| [04:05:20] | jams (jams!~jams@cpe-184-58-217-97.wi.res.rr.com) has joined #mythtv | |
| [04:05:54] | joe_ (joe_!~jmk@64.73.32.135) has quit (Ping timeout: 252 seconds) | |
| [04:05:56] | jpabq: | That is, unless someone like danielk22 knows of a way of setting default values in the channel table based off which device that channel is tuned on. |
| [04:07:15] | jpabq: | taylorr, we may want to force sharpness to 0x80 since that is not a user-adjustable control. |
| [04:08:23] | jpabq: | Actually, I guess we don't have to. Even the current driver has the default for sharpness correct. |
| [04:09:26] | taylorr: | it's the only value it's got right :) |
| [04:09:50] | jpabq: | Makes me wonder if the HD-PVR pays attention to that value. |
| [04:13:12] | jpabq: | taylorr, I was asking if the driver has a version number associated with it, so I could at least make a comment in that code to indicate which driver "lies". |
| [04:14:39] | taylorr: | jpabq: I couldn't tell if sharpness made any difference under windows |
| [04:14:59] | taylorr: | it didn't seem to change when I adjusted it... all the other controls were very noticeable |
| [04:15:11] | jpabq: | That does not surprise me. |
| [04:18:53] | _charly_ (_charly_!kroseneg@sunrise.schmidham.net) has joined #mythtv | |
| [04:31:39] | taylorr: | jpabq: I'm not worried about hue changing by 1... I'm sure it's an artifact of all the transforms that it goes through |
| [04:36:14] | taylorr: | jpabq: is colour the same as saturation? |
| [04:36:27] | jpabq: | taylorr, V4LChannel::ChangePictureAttribute wraps HUE. V4LChannel::InitPictureAttribute does not, but I believe it is assuming the value being read from the DB has already been validated. |
| [04:37:49] | jpabq: | No, colour changes the "tint". e.g. from green to red. Saturation is more like vibrance, e.g. from B/W to color. |
| [04:39:52] | taylorr: | jpabq: the math involved and the values it's starting with is a mystery to me |
| [04:40:18] | jpabq: | "it" being myth? |
| [04:40:39] | taylorr: | I really don't understand what the cfield, sfield, dfield are all about |
| [04:41:10] | jpabq: | I don't either. If necessary, I was going to try and figure that out on Saturday. |
| [04:41:24] | taylorr: | probably a good idea to give that a look over |
| [04:41:41] | taylorr: | the way it's getting 14 instead of 15 is bazarre |
| [04:42:41] | taylorr: | it's taking 32k + 64k + 0 and ANDing with 0xFFFF which would leave you with 32k which is 50% of the hue range and it spits out 14 which is very close |
| [04:43:12] | taylorr: | where does it get hue from? |
| [04:43:24] | taylorr: | it's getting 64k from somewhere |
| [04:43:55] | taylorr: | jpabq: I must admit tuning livetv seems really fast now |
| [04:44:06] | jpabq: | The channel DB table always has 0–65535 as the value range. |
| [04:44:39] | taylorr: | I don't think it has a hue value in the per channel color control does it? |
| [04:45:36] | jpabq: | Yes, it does. in the channel table there are hue, colour, brightness and contrast fields. |
| [04:45:57] | taylorr: | the hdpvr doesn't support colour |
| [04:47:10] | jpabq: | Snap. Right. colour and hue effect the same thing. I wonder why the DB table has both? |
| [04:49:48] | taylorr: | jpabq: I'd be curious if your patch works for the new firmware with old driver code |
| [04:50:01] | jpabq: | the HD-PVR accept a saturation control? It does not look like Myth has a value in the DB for that. |
| [04:50:10] | taylorr: | yes |
| [04:50:28] | taylorr: | look at the patch I posted for the driver... it has all 5 |
| [04:51:26] | jpabq: | taylorr, I will try it this weekend. Have you tried it with your new driver code? |
| [04:53:08] | taylorr: | yes, working great |
| [04:53:30] | jpabq: | I am guessing that whomever design the color controls in Myth made a mistake, and put an entry in for both colour and hue, when one of them should have been saturation. |
| [04:53:40] | jpabq: | with the change of HD-PVR to "hdpvr", I assume. |
| [04:54:19] | jpabq: | I am guessing it will work with the old driver just fine. |
| [04:54:43] | taylorr: | I'm going to go ahead and update my firmware on my other HD-PVR |
| [04:55:15] | taylorr: | do you know if on windows if you have to reinstall the hdpvr software to get the firmware to update |
| [04:55:38] | jpabq: | I dont' think so, but it has been a long time since I have updated the firmware. |
| [04:55:49] | taylorr: | basically I got it installed on the first hdpvr when I installed the software but I'm not sure if I plug in the other one if it will automagically happen or not |
| [04:56:25] | jpabq: | You should be able to tell, by if the orange LED lights up on the HD-PVR. |
| [04:59:50] | taylorr: | it worked |
| [05:01:38] | jedix (jedix!~jedix@24-246-5-37.cable.teksavvy.com) has quit (Ping timeout: 260 seconds) | |
| [05:02:26] | jedix (jedix!~jedix@24-246-5-37.cable.teksavvy.com) has joined #mythtv | |
| [05:03:29] | taylorr (taylorr!~taylorr@unaffiliated/elmojo) has quit (Remote host closed the connection) | |
| [05:05:50] | taylorr (taylorr!~taylorr@cpe-173-095-145-027.nc.res.rr.com) has joined #mythtv | |
| [05:05:50] | taylorr (taylorr!~taylorr@cpe-173-095-145-027.nc.res.rr.com) has quit (Changing host) | |
| [05:05:50] | taylorr (taylorr!~taylorr@unaffiliated/elmojo) has joined #mythtv | |
| [05:07:24] | jpabq: | taylorr, okay, the way Myth is using it, colour == saturation. Not the way I am used to thinking of it from a photography point of view. |
| [05:08:26] | Beirdo: | I'm seeing a lot of "Excluding Descriptor" messages now. Those probably should be at debug level, not info (long term) |
| [05:09:00] | Beirdo: | oh, and "Including Descriptor" :) |
| [05:09:16] | Beirdo: | every 15s or so, it seems |
| [05:09:56] | jpabq: | Beirdo, I changed my default run level to NOTICE because of how verbose mythbackend is these days. I think there are several areas the could stand some re-classification. |
| [05:10:54] | taylorr (taylorr!~taylorr@unaffiliated/elmojo) has quit (Remote host closed the connection) | |
| [05:11:23] | jpabq: | With NOTICE I actually do not get some message that I want to see. |
| [05:11:26] | Beirdo: | most definitely are :) |
| [05:12:08] | Beirdo: | yeah, hopefully we get those all adjusted before release, but yeah, there are a bunch that should likely be tweaked a bit |
| [05:12:17] | Beirdo: | both directions |
| [05:12:27] | taylorr (taylorr!~taylorr@cpe-173-095-145-027.nc.res.rr.com) has joined #mythtv | |
| [05:12:27] | taylorr (taylorr!~taylorr@cpe-173-095-145-027.nc.res.rr.com) has quit (Changing host) | |
| [05:12:27] | taylorr (taylorr!~taylorr@unaffiliated/elmojo) has joined #mythtv | |
| [05:12:37] | jpabq: | The question is, should some things that are now INFO be move to NOTICE, and then the default be set to NOTICE? |
| [05:13:00] | Beirdo: | I don't think so |
| [05:13:11] | jpabq: | So, move more things to DEBUG? |
| [05:13:26] | Beirdo: | hmmm |
| [05:13:57] | jpabq: | #define KERN_NOTICE "<5>" /* normal but significant condition. I would put tuning events, and such there. |
| [05:13:59] | Beirdo: | I guess we'd need to think about it. Moving the default to notice may not be the worst idea, but it would require moving a lot of suff |
| [05:14:25] | Beirdo: | yeah, these are based off syslog levels, but they are pretty similar |
| [05:14:33] | taylorr: | jpabq: bummer, my other hdpvr which is connected via spdif doesn't have sound now |
| [05:15:02] | jpabq: | taylorr, that is even worse than a bummer. |
| [05:15:21] | Beirdo: | that would be nearly rage inspiring for me |
| [05:15:26] | jpabq: | taylorr, you didn't end up with RCA audio ALSO hooked up, did you? If so, that will kill S/PDIF audio. |
| [05:15:41] | taylorr: | hmmm, let me check |
| [05:17:39] | taylorr: | jpabq: that was it |
| [05:17:51] | taylorr: | weird... I never had an issue with 0x15 |
| [05:18:18] | jpabq: | My HD-PVRs have always had that behavior as far back as 0xf |
| [05:19:05] | taylorr: | jpabq: cool thing is that I now longer get any breakup and the very beginning of a recording |
| [05:19:46] | jpabq: | That is nice. You are starting to make me look forward to this "upgrade". |
| [05:19:56] | taylorr: | jpabq: I wonder it we'll be able to reduce some of the timeouts now |
| [05:20:15] | taylorr: | jpabq: did you get that breakup at the very start? |
| [05:21:00] | jpabq: | Yes, but they didn't really bother me too much. They could be mostly eliminated by having a longer sleep at the end of the channel change script. |
| [05:21:23] | taylorr: | where do you put your sleep at exactly? |
| [05:21:35] | taylorr: | could you post your channel change script? |
| [05:22:04] | jpabq: | Sure. Beirdo's is fancier than mine, but I will post mine in a sec. |
| [05:22:09] | taylorr: | it's nice to be the only person on the planet running 0x17 under linux :) |
| [05:22:20] | taylorr: | I'm using Beirdo's |
| [05:22:26] | taylorr: | it's no big deal |
| [05:23:04] | jpabq: | http://mythtv.pastebin.ca/2091689 |
| [05:24:12] | jpabq: | There is some old stuff in there from when Directv was still transitioning to HD on some channels, such that the HD channel number had a -1 at the end. |
| [05:24:43] | jpabq: | So, to get to channel 708–1, it would tune to 708 and then do a channel up. |
| [05:28:00] | jpabq: | taylorr, nice work tonight. I am off to bed. |
| [05:29:13] | taylorr: | I should have went to bed 3 hours ago :) |
| [05:29:21] | taylorr: | good night |
| [05:31:35] | Beirdo: | heh. Night all |
| [05:31:45] | Beirdo: | I think I'll head there myself soon too |
| [05:40:42] | kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has left #mythtv () | |
| [06:44:01] | map7_ (map7_!~map7@ppp118-209-40-224.lns20.mel4.internode.on.net) has joined #mythtv | |
| [07:07:03] | kc (kc!~Casper@unaffiliated/kc) has quit (Ping timeout: 258 seconds) | |
| [07:23:01] | kc (kc!~Casper@unaffiliated/kc) has joined #mythtv | |
| [07:36:48] | kc (kc!~Casper@unaffiliated/kc) has quit (Ping timeout: 240 seconds) | |
| [07:42:12] | map7_ (map7_!~map7@ppp118-209-40-224.lns20.mel4.internode.on.net) has quit (Ping timeout: 240 seconds) | |
| [07:47:14] | willcooke (willcooke!~will@willcooke.plus.com) has joined #mythtv | |
| [07:47:14] | willcooke (willcooke!~will@willcooke.plus.com) has quit (Changing host) | |
| [07:47:14] | willcooke (willcooke!~will@canonical/willcooke) has joined #mythtv | |
| [07:50:17] | kc (kc!~Casper@pool-70-20-140-145.phlapa.east.verizon.net) has joined #mythtv | |
| [07:50:23] | kc (kc!~Casper@pool-70-20-140-145.phlapa.east.verizon.net) has quit (Changing host) | |
| [07:50:23] | kc (kc!~Casper@unaffiliated/kc) has joined #mythtv | |
| [08:24:03] | len (len!~quassel@174-30-241-127.mpls.qwest.net) has quit (Remote host closed the connection) | |
| [09:23:40] | markk (markk!~mark@host86-181-156-164.range86-181.btcentralplus.com) has quit (Remote host closed the connection) | |
| [09:25:24] | markk (markk!~mark@host86-181-156-164.range86-181.btcentralplus.com) has joined #mythtv | |
| [09:31:33] | willcooke (willcooke!~will@canonical/willcooke) has quit (Quit: We will learn more of his wisdom later) | |
| [09:31:49] | willcooke (willcooke!~will@willcooke.plus.com) has joined #mythtv | |
| [09:31:49] | willcooke (willcooke!~will@willcooke.plus.com) has quit (Changing host) | |
| [09:31:50] | willcooke (willcooke!~will@canonical/willcooke) has joined #mythtv | |
| [09:43:15] | map7_ (map7_!~map7@ppp118-209-40-224.lns20.mel4.internode.on.net) has joined #mythtv | |
| [09:48:17] | pheld (pheld!~heldal@cl-5.osl-01.no.sixxs.net) has joined #mythtv | |
| [10:02:00] | markk (markk!~mark@host86-181-156-164.range86-181.btcentralplus.com) has quit (Ping timeout: 240 seconds) | |
| [10:05:02] | Guest70147 (Guest70147!~mike@c-24-21-63-118.hsd1.or.comcast.net) has quit (Remote host closed the connection) | |
| [10:05:59] | mike|2 (mike|2!~mike@c-24-21-63-118.hsd1.or.comcast.net) has joined #mythtv | |
| [10:22:40] | markk (markk!~mark@host109-150-240-46.range109-150.btcentralplus.com) has joined #mythtv | |
| [11:11:18] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya) | |
| [11:23:53] | map7_ (map7_!~map7@ppp118-209-40-224.lns20.mel4.internode.on.net) has quit (Ping timeout: 258 seconds) | |
| [11:33:52] | brfransen (brfransen!~brfransen@216.254.250.47) has quit (Ping timeout: 255 seconds) | |
| [11:39:13] | reynaldo (reynaldo!~rverdejo@pc-147-56-101-190.cm.vtr.net) has quit (Ping timeout: 258 seconds) | |
| [11:39:53] | reynaldo (reynaldo!~rverdejo@pc-147-56-101-190.cm.vtr.net) has joined #mythtv | |
| [11:46:50] | brfransen (brfransen!~brfransen@216.254.250.47) has joined #mythtv | |
| [12:06:00] | davide (davide!~david@host70.16.intrusion.com) has quit (Remote host closed the connection) | |
| [12:06:29] | davide (davide!~david@host70.16.intrusion.com) has joined #mythtv | |
| [12:26:54] | PointyPumper (PointyPumper!~pintlezz@190.244.65.185) has quit (Read error: Connection reset by peer) | |
| [12:37:22] | PointyPumper (PointyPumper!~pintlezz@190.244.65.185) has joined #mythtv | |
| [13:03:26] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv | |
| [13:06:28] | map7_ (map7_!~map7@ppp118-209-40-224.lns20.mel4.internode.on.net) has joined #mythtv | |
| [13:18:26] | jarle (jarle!~jarle@70.84-234-133.customer.lyse.net) has quit (Remote host closed the connection) | |
| [13:18:43] | taylorr: | sphery: I like Kevin's idea to have a cron job run with --refresh-today right before primetime – do you think that's a good idea? |
| [13:19:18] | taylorr: | danielk22: I think we got most everything figured out for the hdpvr picture controls |
| [13:20:31] | taylorr: | I think the per channel picture control values of 32768 are just fine since it seems the code normalizes them based on what the driver reports as the range and default for each picture control |
| [13:26:38] | map7_ (map7_!~map7@ppp118-209-40-224.lns20.mel4.internode.on.net) has quit (Ping timeout: 245 seconds) | |
| [13:28:43] | map7_ (map7_!~map7@ppp118-209-40-224.lns20.mel4.internode.on.net) has joined #mythtv | |
| [13:33:41] | map7_ (map7_!~map7@ppp118-209-40-224.lns20.mel4.internode.on.net) has quit (Ping timeout: 252 seconds) | |
| [14:11:58] | j-rod|afk is now known as j-rod | |
| [14:25:08] | stuartm: | sphery: date formats _are_ translatable through the locale configs |
| [14:27:48] | iamlindoro: | taylorr: It may work okay, but it's kind of a douchey thing to do to SD-- why not just limit your SD window to 3–6 PM and run with --dd-grab-all? |
| [14:28:27] | taylorr: | oh, I thought just doing --refresh-today wouldn't be a big hit |
| [14:29:36] | iamlindoro: | I just mean that doing --refresh-today as well as presumably allowing the backend to run its regular job, all of which requires the TMS side to puzzle out exactly which programming to give you, and the today portion twice in one day-- is not exactly a "friendcly" thing to do |
| [14:29:43] | iamlindoro: | er friendly |
| [14:30:52] | taylorr: | actually, I was thinking to run --refresh-today at 6AM and 6PM every day |
| [14:33:46] | iamlindoro: | taylorr: Why not just use --dd-grab-all with a small window just before primetime? |
| [14:33:59] | iamlindoro: | Then you get all days, fresh data for that night, it's friendlier to SD, etc. |
| [14:34:07] | cattelan_away is now known as cattelan | |
| [14:36:01] | taylorr: | I guess I could |
| [14:44:14] | taylorr: | is there a convenience function that rounds up a float if the fraction is >= 0.5? |
| [14:45:24] | iamlindoro: | ceil? |
| [14:45:40] | taylorr: | that only rounds up |
| [14:45:48] | taylorr: | so 0.4 would be 1.0 |
| [14:47:13] | iamlindoro: | how about floor(x + 0.5) ? |
| [14:48:23] | stuartm: | would still round down if < 0.5 |
| [14:48:58] | iamlindoro: | no |
| [14:49:09] | iamlindoro: | if x = 1.4, you'll get 1 |
| [14:49:15] | iamlindoro: | if x = 1.5, you'll get 2 |
| [14:49:21] | stuartm: | right, and 0.4 you'd get 0 |
| [14:49:23] | taylorr: | or ceil(x – 0.5) should work |
| [14:49:45] | iamlindoro: | stuartm: Which is in line with what he asked for |
| [14:49:55] | stuartm: | iamlindoro: that's not how I read it |
| [14:50:10] | stuartm: | but if that's what he's after, it would work |
| [14:50:20] | taylorr: | yes, either floor(x +0.5) or ceil(x – 0.5) should work the same |
| [14:50:45] | taylorr: | stuartm: I wanted 1.4 to be 1.0 and 1.5 to be 2.0 |
| [14:51:09] | taylorr: | trying to fix a problem with rounding and picture controls |
| [14:51:15] | jpabq_ (jpabq_!~jpabq@mythtv/developer/jpabq) has joined #mythtv | |
| [14:57:09] | taylorr: | jpabq: the picture control code should work fine for picture code defaults that are 25% and not 50% |
| [14:57:33] | taylorr: | I believe the mythtv code normalizes based on the min/max/default that the driver reports |
| [14:57:54] | taylorr: | so 32768 is 50% in mythtv but sets the driver to 25% |
| [14:58:06] | taylorr: | basically the mythtv controls are relative to the driver defaults |
| [14:58:24] | taylorr: | danielk22: ^^^ is this correct? |
| [15:01:08] | kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has joined #mythtv | |
| [15:22:00] | danielk22: | floor/ceil/round.. round is the one you want for rounding >=0.5 up and <0.5 .. the functions are in <cmath> |
| [15:22:58] | danielk22: | taylorr: the range in the DB is 0..65535 this is normalized to whatever the driver range is, be it -128..127, or 0..64, or anything else. |
| [15:23:44] | taylorr: | it's also normalized relative to the default control value |
| [15:24:10] | danielk22: | The default value in the DB is 0+32768, so in the -128..127 case this is 0, in the 0..64 case this is 32. |
| [15:24:54] | danielk22: | The default control value is not used at all. Our default is half-way between the min and max. |
| [15:25:43] | taylorr: | that's not happening in practice though |
| [15:26:42] | taylorr: | ie. saturation for the hdpvr has max=255, min=0 and default=64 |
| [15:27:28] | danielk22: | taylorr: then we need to set the capturecard table's saturation column to something other than 0.. |
| [15:27:36] | taylorr: | according to how you explained it 32768 in myth should cause the value to be set to 128... however when I run the code I'm getting 64 |
| [15:27:57] | taylorr: | the code is doing the right thing |
| [15:28:10] | taylorr: | at least as far as I can tell |
| [15:28:49] | taylorr: | all I'm saying is that it appears that the mythtv setting is relative to the driver default value |
| [15:29:06] | danielk22: | taylorr: I don't see how that would happen looking at the code. Did you try looking at the values in the set function? |
| [15:29:35] | taylorr: | I dunno, it's odd that it works |
| [15:29:52] | taylorr: | I believe John may take a look at this over the weekend |
| [15:29:58] | taylorr: | I don't have any more time to spend on it |
| [15:30:23] | taylorr: | danielk22: do you use an HDPVR in production? |
| [15:30:58] | danielk22: | taylorr: there is card specific override for the pcHDTV in v4lchannel, but nothing for the hdpvr. |
| [15:31:31] | danielk22: | taylorr: Yeah, I'm on my third one, these things burn out.. |
| [15:31:59] | Goga777 (Goga777!~Goga777@shpd-178-64-247-162.vologda.ru) has joined #mythtv | |
| [15:32:07] | danielk22: | ah, it looks like the values are relative to default.. |
| [15:32:27] | danielk22: | v4lchannel.cpp:875 ! |
| [15:33:13] | danielk22: | At least when there isn't an override for funky driver defaults, like we have for the pcHDTV HD-3000 card. |
| [15:33:44] | taylorr: | danielk22: I read that round() was added to C99 – is it safe to use then... while older distros not compile? |
| [15:34:12] | taylorr: | s/while/will/ |
| [15:34:15] | danielk22: | As I understand it we can do an override like that for the hdpvr for people running older versions of the driver. |
| [15:34:46] | taylorr: | danielk22: you don't want to do the override there for the hdpvr |
| [15:35:07] | taylorr: | John posted a patch last night that intercepted the query and return the correct driver values |
| [15:35:13] | danielk22: | taylorr: in theory C++ doesn't support C99, but I don't know of any shipping compiler that doesn't support that. |
| [15:36:39] | taylorr: | it doesn't really matter... round() is symmetrical where floor(x+0.5) isn't but for positive numbers it doesn't matter and I'm pretty sure we won't encounter negeative numbers there |
| [15:36:41] | danielk22: | taylorr: you recently added pts decoding in the recorder right? |
| [15:37:05] | taylorr: | danielk22: I added parsing for repeat_pict but pts should be easy enough |
| [15:38:03] | taylorr: | I've got changes that should make it easy for us to port the mpegvideoparser code from libav to expand our parsing capabilities |
| [15:40:33] | danielk22: | taylorr: I don't really want to do that much decoding in the recorder. ffmpeg is a bit to crashy to use in the backend. But decoding some basics like PTS might be useful for monitoring the health of an ongoing recording. |
| [15:41:52] | taylorr: | danielk22: right, the parser is just extracting values... it shoulnd't cause stability problems |
| [15:46:27] | taylorr: | danielk22: fyi, those pcHDTV HD-3000 overrides are actually overriding the mythtv values not the driver defaults |
| [15:46:59] | taylorr: | they probably should have did those overrides like jpabq is proposing to do for the hdpvr |
| [15:47:32] | taylorr: | hdpvr driver patch posted to linux-media ML – hopefully they're more responsive than ffmpeg :) |
| [15:48:33] | danielk22: | taylorr: yep, should have been an offset. |
| [15:59:25] | jmartens (jmartens!~jmartens@s5597ca60.adsl.wanadoo.nl) has joined #mythtv | |
| [17:06:41] | davide (davide!~david@host70.16.intrusion.com) has quit (Remote host closed the connection) | |
| [17:07:07] | davide (davide!~david@host70.16.intrusion.com) has joined #mythtv | |
| [17:11:20] | Goga777 (Goga777!~Goga777@shpd-178-64-247-162.vologda.ru) has quit (Remote host closed the connection) | |
| [17:25:31] | andreax (andreax!~andreaz@p4FC13A1C.dip.t-dialin.net) has joined #mythtv | |
| [17:27:56] | jmartens (jmartens!~jmartens@s5597ca60.adsl.wanadoo.nl) has quit (Quit: Leaving.) | |
| [17:35:21] | jpabq_ (jpabq_!~jpabq@mythtv/developer/jpabq) has quit (Ping timeout: 255 seconds) | |
| [17:37:16] | willcooke (willcooke!~will@canonical/willcooke) has quit (Quit: We will learn more of his wisdom later) | |
| [17:41:56] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [17:42:27] | davide: | sphery: you should talk to eric sharkey about the schema changes! :) seriously, i haven't given it much thought. anyway, the solution i was looking for is to set the videosource to "no grabber" in mythtv-setup. mfdb will then ignore it. |
| [17:44:56] | davide: | jpabq: the s/h on my spare hdpvrs is a b*itch! besides, if you had another one, you'd just record more. :) i'll probably keep one hdpvr in case i add premium channels that aren't copy free. i have a friend who might buy the other one if he doesn't switch to fios. |
| [17:48:24] | Anduin (Anduin!~awithers@pdpc/supporter/professional/anduin) has quit (Ping timeout: 255 seconds) | |
| [17:52:54] | xavierh (xavierh!~chatzilla@cpc1-swin3-0-0-cust920.3-1.cable.virginmedia.com) has joined #mythtv | |
| [19:11:41] | len (len!~quassel@174-30-241-127.mpls.qwest.net) has joined #mythtv | |
| [19:46:31] | Anduin (Anduin!~awithers@pdpc/supporter/professional/anduin) has joined #mythtv | |
| [20:28:17] | taylorr: | if I'm passing a uint8 value to an int argument of a function do I need to cast the uint8 to int when I call the function? |
| [20:57:41] | map7_ (map7_!~map7@ppp118-209-40-224.lns20.mel4.internode.on.net) has joined #mythtv | |
| [21:04:18] | jya (jya!~jyavenard@60-242-40-141.static.tpgi.com.au) has joined #mythtv | |
| [21:04:18] | jya (jya!~jyavenard@60-242-40-141.static.tpgi.com.au) has quit (Changing host) | |
| [21:04:19] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [21:06:57] | danielk22: | taylorr: Nope, conversions to wider types are automatic and safe. |
| [21:08:03] | danielk22: | (Well safe so long as the signedness is correct). |
| [21:11:13] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 245 seconds) | |
| [21:12:30] | taylorr: | danielk22: thanks, I always wondered about that |
| [21:22:00] | map7_ (map7_!~map7@ppp118-209-40-224.lns20.mel4.internode.on.net) has quit (Ping timeout: 244 seconds) | |
| [21:29:40] | jmartens (jmartens!~jmartens@s5597ca60.adsl.wanadoo.nl) has joined #mythtv | |
| [21:40:45] | j-rod is now known as j-rod|afk | |
| [21:48:46] | map7_ (map7_!~map7@1.152.209.5) has joined #mythtv | |
| [21:53:36] | map7_ (map7_!~map7@1.152.209.5) has quit (Ping timeout: 240 seconds) | |
| [21:56:11] | jmartens (jmartens!~jmartens@s5597ca60.adsl.wanadoo.nl) has quit (Quit: Leaving.) | |
| [21:56:41] | markk (markk!~mark@host109-150-240-46.range109-150.btcentralplus.com) has quit (Quit: Ex-Chat) | |
| [22:02:35] | stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has quit (Ping timeout: 276 seconds) | |
| [22:05:14] | markk (markk!~mark@host109-150-240-46.range109-150.btcentralplus.com) has joined #mythtv | |
| [22:12:52] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit () | |
| [22:16:54] | xavierh (xavierh!~chatzilla@cpc1-swin3-0-0-cust920.3-1.cable.virginmedia.com) has quit (Remote host closed the connection) | |
| [22:36:54] | andreax (andreax!~andreaz@p4FC13A1C.dip.t-dialin.net) has quit (Read error: Connection reset by peer) | |
| [23:11:15] | cocoa117 (cocoa117!~cocoa117@178.102.129.161) has joined #mythtv | |
| [23:19:15] | cocoa117 (cocoa117!~cocoa117@178.102.129.161) has quit (Quit: Leaving) | |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.
