| Saturday, April 14th, 2012, 00:08 UTC | ||
| [00:08:31] | danielk22: | taylorr: The backend CPU usage was due to checking the time too frequently. It was fixed about 6 weeks ago. |
| [00:09:30] | danielk22: | For some reason QDateTime is much slower on some machines than others. Maybe something to do with timezone conversion? |
| [00:24:43] | kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has quit (Quit: kormoc) | |
| [00:24:48] | zombor (zombor!~zombor_@65.29.231.135) has joined #mythtv | |
| [00:24:48] | zombor (zombor!~zombor_@65.29.231.135) has quit (Changing host) | |
| [00:24:48] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [00:28:37] | taylorr: | awesome, thanks for the info |
| [00:29:42] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [00:47:36] | Twiggy2cents (Twiggy2cents!~darren@173-25-90-98.client.mchsi.com) has quit (Remote host closed the connection) | |
| [00:54:51] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Remote host closed the connection) | |
| [01:11:00] | kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has joined #mythtv | |
| [01:12:01] | jya: | danielk22: any plans of backporting b2657a1a3f8aa7210885a9699b620634e4043363 and 0c00c0ac960df077d558959b1726c4b9801852c3 |
| [01:14:38] | Captain_Murdoch: | gigem, should be fixed now. that was an error with my cron that copies the new index into place after the ftp rsync. I just ran it manually and it's updated now. |
| [01:18:15] | Captain_Murdoch: | may take a while for it to show up for you, if you want it quicker, remove ~/.mythtv/tmp/themes.zip so the index will get re-downloaded |
| [01:39:38] | plink212 (plink212!~tim@S0106c0c1c01b51cf.vc.shawcable.net) has joined #mythtv | |
| [01:41:55] | plink212: | should the 0.25-fixes branch be complete and buildable yet? as it seems to be missing files from extras |
| [01:42:15] | ElmerFudd (ElmerFudd!~le@0x5737a682.cpe.ge-0-1-0-1101.hsnqu1.customer.tele.dk) has quit (Read error: Operation timed out) | |
| [01:55:34] | stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has quit (Ping timeout: 272 seconds) | |
| [02:04:34] | stichnot (stichnot!chatzilla@mythtv/developer/stichnot) has joined #mythtv | |
| [02:27:52] | danielk22: | jya: Yeah, but I'm going to be away all next week so I'm reluctant to make big commits to master and even small commits to fixes since I may not be able to revert or fix any oopses until I get back from the show. |
| [02:28:37] | jya: | danielk22: those changes you made on xvideo are trivial.. sufficiently simple that I can look after any issues arising |
| [02:28:53] | danielk22: | jya: If you want to cherry pick them and take the responsibility of reverting/fixing in case of problems while I'm away that's great. :) |
| [02:29:04] | jya: | deal :) |
| [02:29:20] | jya: | the smurfing of people in video playback has been noticed by many |
| [02:29:38] | jya: | i'm surprised that this issue seems to be occrring just now |
| [02:29:59] | jya: | surely, people would have noticed it before… i wonder what has changed lately.. there's nothing obvious |
| [02:30:39] | danielk22: | Me too. My guess is a lot of the people running master use nvidia cards. |
| [02:32:14] | jya: | sure, but the issue affected me too in vmware.. maybe they are people who upgraded to ubuntu 12.04 |
| [02:32:26] | ** jya getting power adapter, laptop is running flat ** | |
| [02:32:27] | danielk22: | We made the change to enable picture controls early in the 0.25 release cycle in hopes of catching anything like this before release. |
| [02:33:14] | Beirdo: | jya: my thought would be (re backports)... |
| [02:33:30] | Beirdo: | bug fixes should be pretty much a nobrainer if someone has the time |
| [02:33:42] | Beirdo: | new features... maybe shouldn't be backported at all |
| [02:33:58] | Beirdo: | of course, the distinguishing line is often hard to see |
| [02:34:04] | jya: | Beirdo: i had no intention on backporting new features.. i value my time too much |
| [02:34:09] | Beirdo: | heh :) |
| [02:34:19] | Beirdo: | yeah, I figured as much |
| [02:34:29] | Beirdo: | now how to define that line, hell if I know |
| [02:34:50] | jya: | having said that, I think it would be a great idea to have a fixes/0.25 branch that includes most changes not requiring a db change |
| [02:35:15] | jya: | like i did with my 0.24 backport branch… it makes for a much greater experience |
| [02:35:37] | Beirdo: | yah, but... it also makes for a less defined... release differentiation |
| [02:36:05] | Beirdo: | I dunno |
| [02:36:09] | Beirdo: | just my thoughts :) |
| [02:37:03] | danielk22: | jya: I wouldn't mind a backports/0.24 in addition to the fixes/0.24, I think it needs to be floated with the other devs, but there are often things that are really worth while and simple/safe but technically new features. |
| [02:37:44] | Beirdo: | danielk22: my issue with that in particular: 0.24 is over a year ago |
| [02:37:51] | Beirdo: | how long will we keep backporting to it? |
| [02:38:08] | jya: | i think we should stop once a new major release is out |
| [02:38:11] | Beirdo: | and how many future revisions will we be backporting to? |
| [02:38:20] | danielk22: | heh, I mean backports/0.25.. It's like the new year it takes a while for me to adjust what I write. |
| [02:38:29] | Beirdo: | ahhh |
| [02:38:30] | jya: | and in my experience, this stop much earlier than that, because all changes become way too complex to backports |
| [02:38:31] | Beirdo: | whew |
| [02:39:04] | Beirdo: | I was gonna say, if we are still backporting to 0.24 when we hit 0.26, it's gonna get very messy to maintain |
| [02:39:25] | Beirdo: | so a backports/0.25 while in 0.26 dev cycle.. hmm |
| [02:39:39] | Beirdo: | yeah, that has some use if someone has the energy to do it |
| [02:41:47] | jya: | could rename my backport branch to backports/0.24 |
| [02:42:20] | jya: | keeping in mind, i dont see me doing any more work to it |
| [02:42:26] | Beirdo: | yeah, that could be done. If we get "concensus" or whatever, it wouldn't be a problem |
| [02:42:37] | Beirdo: | I think it's a good plan, personally |
| [02:42:47] | Beirdo: | seems danielk22's not against the idea :) |
| [02:43:05] | Beirdo: | still a bunch of other voices in the choir and all |
| [02:45:37] | Beirdo: | we'd have to work out the support ramifications, etc, but I think we'd be able to find something workable :) |
| [03:02:40] | skd5aner: | My $0.02 – quicker release cycles, and only backport things that really are holding people up (i.e., stuff that made cablecard tuners work when they were released) |
| [03:03:32] | skd5aner: | trying to maintain things across two "releases" is more trouble than it's worth. Have a quicker release cycle and work on branches if it's going to take longer than 1 release to work on a new feature/rewrite/etc |
| [03:08:26] | skd5aner: | with branching, it shoudl be extremely feasible to set (and stick to) a X month release cycle |
| [03:09:13] | skd5aner: | anyway – have a good weekend everyone... great work with this release this week! :) |
| [03:09:18] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [03:09:18] | ** skd5aner goes to bed ** | |
| [03:09:28] | skd5aner: | (and thanks again) |
| [03:10:12] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [03:25:22] | clever_ (clever_!~clever@142.167.219.82) has joined #mythtv | |
| [03:26:12] | clever (clever!~clever@142.167.219.82) has quit (Ping timeout: 265 seconds) | |
| [03:26:12] | XDS2010_ (XDS2010_!u1218@gateway/web/irccloud.com/x-dssusrouvurykgnq) has quit (Ping timeout: 265 seconds) | |
| [03:26:56] | XDS2010_ (XDS2010_!u1218@gateway/web/irccloud.com/x-myzukxncqwecggen) has joined #mythtv | |
| [03:27:05] | mzanetti (mzanetti!~mzanetti@server1.muehlhaeuser.de) has quit (Ping timeout: 265 seconds) | |
| [03:28:51] | mzanetti (mzanetti!~mzanetti@server1.muehlhaeuser.de) has joined #mythtv | |
| [03:31:14] | plink212 (plink212!~tim@S0106c0c1c01b51cf.vc.shawcable.net) has quit (Quit: plink212) | |
| [03:31:50] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [03:58:32] | xris: | scheduler is definitely odd in .25 |
| [03:58:45] | xris: | seems to be ignoring show recpriorities |
| [04:02:56] | xris: | ah, I see. I think I had input priorities backwards. and I was trying too hard to pick values |
| [04:04:40] | xris: | wondering what the difference is between scheduler order and recpriority? |
| [04:04:52] | xris: | are we going to eventually kill recpriority? |
| [04:07:37] | xris: | ah, I think I got it. when the new field was created, it looks like it was set it to the value of recpriority. but they're actually inverse (important == high recpriority == low scheduler order). a bit confusing. |
| [04:08:17] | xris: | pity that back-to-back recordings cause one to get de-prioritized. multirec solved that ages ago. |
| [04:24:36] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [05:13:38] | [R] ([R]!~rbox@unaffiliated/rbox) has joined #mythtv | |
| [05:15:44] | sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Read error: Operation timed out) | |
| [05:24:05] | jya_ (jya_!~jyavenard@120.148.99.165) has joined #mythtv | |
| [05:24:05] | jya_ (jya_!~jyavenard@120.148.99.165) has quit (Changing host) | |
| [05:24:05] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [05:30:40] | sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv | |
| [05:35:11] | cattelan is now known as cattelan_away | |
| [06:08:42] | stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has quit (Remote host closed the connection) | |
| [06:33:19] | hashbang (hashbang!~alex@213-152-35-50.dsl.eclipse.net.uk) has joined #mythtv | |
| [06:34:37] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_) | |
| [06:56:10] | [R] ([R]!~rbox@unaffiliated/rbox) has quit (Quit: Leaving) | |
| [07:13:52] | jya: | anyone with experience on how the selection of playback profiles actually work ? |
| [07:14:48] | jya: | for example, I've created a vaapi profile that uses vaapi decoding to use with the vaapi deinterlacers as choice 1. As choice 2, I put ffmpeg decoder, opengl rendering and opengl hardware deinterlacer |
| [07:15:36] | jya: | watching a mpeg2 video, mpeg2 isn't accepted as codec by vaapi, so it default to ffmpeg automatically.. however, it doesn't default back to another profile entry so the video isn't deinterlaced |
| [07:18:45] | jya: | there doesn't seem to be any fallback to a different entry in a playback profile, should one got accepted first, only for later to fail because a particular codec isn't accepted |
| [07:31:55] | MythBuild: | build #3649 of master-linux-64bit is complete: Failure [4failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/3649 blamelist: Jean-Yves Avenard <jyavenard@mythtv.org > |
| [07:32:01] | MythBuild: | build #2363 of master-linux-ppc is complete: Failure [4failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/2363 blamelist: Jean-Yves Avenard <jyavenard@mythtv.org > |
| [07:32:56] | MythBuild: | build #3382 of master-linux-32bit is complete: Failure [4failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/3382 blamelist: Jean-Yves Avenard <jyavenard@mythtv.org > |
| [07:34:12] | MythBuild: | build #2126 of master-debian-stable-64bit is complete: Failure [4failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/2126 blamelist: Jean-Yves Avenard <jyavenard@mythtv.org > |
| [07:34:44] | MythBuild: | build #2433 of master-freebsd-64bit is complete: Failure [4failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/2433 blamelist: Jean-Yves Avenard <jyavenard@mythtv.org > |
| [07:43:55] | MythBuild: | build #837 of master-osx-snow-leopard is complete: Failure [4failed compile] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . d/builds/837 blamelist: Jean-Yves Avenard <jyavenard@mythtv.org > |
| [07:49:45] | CaCtus491 (CaCtus491!~Kent@123-243-197-152.static.tpgi.com.au) has quit (Ping timeout: 265 seconds) | |
| [07:51:26] | CaCtus491 (CaCtus491!~Kent@123-243-197-152.static.tpgi.com.au) has joined #mythtv | |
| [08:02:41] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [08:05:57] | jya: | Beirdo: in the buildbot, can you move the master on the left side ? and 0.24 on the right ? I'm guessing there won't be much more 0.24 changes, and the buildbot waterfall screen doesn't fit on my 11" :) |
| [08:06:29] | Beirdo: | not sure if we can |
| [08:07:04] | Beirdo: | I'll check if there's any way to tell it the order, but for now, it's alphabetical |
| [08:08:56] | MythBuild: | build #3651 of master-linux-64bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/3651 |
| [08:11:24] | Beirdo: | oooh |
| [08:11:36] | Beirdo: | you can do: http://code.mythtv.org/buildbot/waterfall?category=master |
| [08:11:44] | Beirdo: | and it will show only the master builds |
| [08:11:56] | Beirdo: | not quite what we were looking for, but it can help |
| [08:12:55] | jya: | problem is that I will never remember that URL |
| [08:13:03] | jya: | i go to it from code.mythtv.org |
| [08:14:06] | jya: | righto… be back online in about an hour, and check those builds .... |
| [08:14:30] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya) | |
| [08:15:45] | Beirdo: | don't see anything in the documentation that affects the sorting. |
| [08:15:46] | Beirdo: | bah |
| [08:16:43] | Goga777 (Goga777!~Goga777@95-30-1-27.broadband.corbina.ru) has joined #mythtv | |
| [08:18:25] | stoffel (stoffel!~quassel@pD9E42D7E.dip.t-dialin.net) has joined #mythtv | |
| [08:18:37] | MythBuild: | build #3384 of master-linux-32bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/3384 |
| [08:19:54] | jya (jya!~jyavenard@120.148.99.165) has joined #mythtv | |
| [08:19:55] | jya (jya!~jyavenard@120.148.99.165) has quit (Changing host) | |
| [08:19:55] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [08:20:19] | MythBuild: | build #2436 of master-freebsd-64bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/2436 |
| [08:20:57] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Client Quit) | |
| [08:23:16] | MythBuild: | build #2129 of master-debian-stable-64bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/2129 |
| [08:26:59] | MythBuild: | build #840 of master-osx-snow-leopard is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . d/builds/840 |
| [08:36:12] | MythBuild: | build #2366 of master-linux-ppc is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/2366 |
| [08:40:01] | kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has quit (Ping timeout: 244 seconds) | |
| [08:57:51] | joe___ (joe___!~bob@64.73.32.135) has joined #mythtv | |
| [08:59:11] | joe__ (joe__!~bob@64.73.32.135) has quit (Ping timeout: 260 seconds) | |
| [09:05:05] | peitolm_ (peitolm_!~moreyc@mandlebrot.random-chaos.org.uk) has quit (Ping timeout: 260 seconds) | |
| [09:10:08] | peitolm (peitolm!~moreyc@mandlebrot.random-chaos.org.uk) has joined #mythtv | |
| [09:15:35] | CaCtus491 (CaCtus491!~Kent@123-243-197-152.static.tpgi.com.au) has quit (Ping timeout: 260 seconds) | |
| [09:19:20] | Goga777 (Goga777!~Goga777@95-30-1-27.broadband.corbina.ru) has quit (Remote host closed the connection) | |
| [09:21:25] | peitolm (peitolm!~moreyc@mandlebrot.random-chaos.org.uk) has quit (Ping timeout: 260 seconds) | |
| [09:21:33] | peitolm (peitolm!~moreyc@mandlebrot.random-chaos.org.uk) has joined #mythtv | |
| [09:22:12] | CaCtus491 (CaCtus491!~Kent@123-243-197-152.static.tpgi.com.au) has joined #mythtv | |
| [09:30:21] | dekarl1 (dekarl1!~dekarl@p4FCEE31A.dip.t-dialin.net) has joined #mythtv | |
| [09:31:51] | dekarl (dekarl!~dekarl@p4FE857CB.dip.t-dialin.net) has quit (Ping timeout: 260 seconds) | |
| [10:03:42] | ben1066_ (ben1066_!~quassel@host86-167-178-215.range86-167.btcentralplus.com) has joined #mythtv | |
| [10:04:17] | ben1066 (ben1066!~quassel@unaffiliated/ben1066) has quit (Ping timeout: 246 seconds) | |
| [10:05:02] | mike|3 (mike|3!~mike@c-98-232-220-158.hsd1.or.comcast.net) has quit (Remote host closed the connection) | |
| [10:05:48] | mike (mike!~mike@c-98-232-220-158.hsd1.or.comcast.net) has joined #mythtv | |
| [10:06:14] | mike is now known as Guest60669 | |
| [10:06:41] | jya (jya!~jyavenard@CPE-60-224-5-57.srql1.win.bigpond.net.au) has joined #mythtv | |
| [10:06:41] | jya (jya!~jyavenard@CPE-60-224-5-57.srql1.win.bigpond.net.au) has quit (Changing host) | |
| [10:06:41] | jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [10:08:42] | andreax (andreax!~andreaz@p54BF1D03.dip.t-dialin.net) has joined #mythtv | |
| [10:09:11] | ben1066 (ben1066!~quassel@host109-152-48-149.range109-152.btcentralplus.com) has joined #mythtv | |
| [10:11:19] | ben1066_ (ben1066_!~quassel@host86-167-178-215.range86-167.btcentralplus.com) has quit (Ping timeout: 276 seconds) | |
| [10:20:06] | sannes (sannes!~ace@cm-84.209.72.206.getinternet.no) has joined #mythtv | |
| [10:53:34] | AndyUbuntu (AndyUbuntu!~quassel@cpc1-sotn6-0-0-cust689.15-1.cable.virginmedia.com) has joined #mythtv | |
| [11:21:25] | ben1066 (ben1066!~quassel@host109-152-48-149.range109-152.btcentralplus.com) has quit (Changing host) | |
| [11:21:26] | ben1066 (ben1066!~quassel@unaffiliated/ben1066) has joined #mythtv | |
| [11:31:26] | rsiebert_ (rsiebert_!~quassel@g231186244.adsl.alicedsl.de) has quit (Remote host closed the connection) | |
| [11:44:05] | rooaus (rooaus!~rooaus@ppp59-167-126-229.static.internode.on.net) has joined #mythtv | |
| [12:11:26] | rooaus: | Interesting idea regarding back ports branch, a different but related idea would be a rolling release off a stable branch. But the continual need to cherry-picking/porting rather than branching may be more effort. |
| [12:17:48] | ben1066_ (ben1066_!~quassel@host109-152-40-19.range109-152.btcentralplus.com) has joined #mythtv | |
| [12:18:43] | rooaus (rooaus!~rooaus@ppp59-167-126-229.static.internode.on.net) has quit (Ping timeout: 264 seconds) | |
| [12:20:01] | ben1066 (ben1066!~quassel@unaffiliated/ben1066) has quit (Ping timeout: 276 seconds) | |
| [12:20:30] | ben1066_ (ben1066_!~quassel@host109-152-40-19.range109-152.btcentralplus.com) has quit (Client Quit) | |
| [12:20:58] | ben1066 (ben1066!~quassel@host109-152-40-19.range109-152.btcentralplus.com) has joined #mythtv | |
| [12:21:34] | rooaus (rooaus!~rooaus@ppp59-167-126-229.static.internode.on.net) has joined #mythtv | |
| [12:22:22] | ben1066 (ben1066!~quassel@host109-152-40-19.range109-152.btcentralplus.com) has quit (Changing host) | |
| [12:22:22] | ben1066 (ben1066!~quassel@unaffiliated/ben1066) has joined #mythtv | |
| [12:40:42] | knightr_: | stuartm, I didn't want to say it that bluntly but garbage-in, garbage-out... The clock being a special case with no possibiliyu of other %VARS% maybe something could have been to handle invalid %VARS% but I didn't think it was worth it to do anything about it... |
| [12:48:30] | knightr_: | he wanted to know what caused what he saw (even though he had already identified the cause of it) he knows it now... |
| [13:26:45] | danielk22: | jya: That is a regression in the playback profiles. Mark removed the code that filtered on codec capability. I think he wanted to restructure it to be more efficient but he never got around to it. |
| [13:29:33] | danielk22: | jya: I think he saw it as a feature of the past i.e. for NUV support, but I saw it as something for the future, h.264 advanced profiles, webm, etc. |
| [13:31:09] | danielk22: | jya: That said, fallback within a single videoout_* should still work. |
| [13:47:01] | stuartm (stuartm!~stuartm@cpc1-derb9-0-0-cust441.8-3.cable.virginmedia.com) has joined #mythtv | |
| [13:47:02] | stuartm (stuartm!~stuartm@cpc1-derb9-0-0-cust441.8-3.cable.virginmedia.com) has quit (Changing host) | |
| [13:47:02] | stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has joined #mythtv | |
| [13:49:37] | stichnot: | danielk22: in your live tv tests, what filesystem type are you using? |
| [13:54:40] | stichnot: | I ask because my recording directory is ext4, but when I remount with barrier=0, I get virtually flawless live TV playback (except for the expected burp at program transitions) |
| [13:55:49] | stichnot: | this is with the 30s transition patch, and backing out all the recent improvements/bandaids, i.e. the live TV torture test |
| [14:09:15] | ben1066_ (ben1066_!~quassel@host86-164-181-145.range86-164.btcentralplus.com) has joined #mythtv | |
| [14:11:49] | ben1066 (ben1066!~quassel@unaffiliated/ben1066) has quit (Ping timeout: 276 seconds) | |
| [14:40:19] | danielk22: | stichnot: ? I'm not having any problems other than the "burp" at program transitions. |
| [14:59:13] | stichnot: | danielk22: I'm talking about #10490, where live TV exits to the main menu at a program transition with "Video frame buffering failed too many times. " I can reproduce it reliably with ext4 defaults, but when I remount with barrier=0, the problem goes away. |
| [14:59:13] | ** MythLogBot http://code.mythtv.org/trac/ticket/10490 ** | |
| [14:59:41] | stichnot: | I'm wondering if you're using a non-ext4 file system, or already using barrier=0, and that's why you weren't seeing the probelm. |
| [15:10:30] | kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has joined #mythtv | |
| [15:13:55] | rooaus (rooaus!~rooaus@ppp59-167-126-229.static.internode.on.net) has quit (Quit: rooaus) | |
| [15:21:35] | rsiebert (rsiebert!~quassel@e179129109.adsl.alicedsl.de) has joined #mythtv | |
| [15:24:01] | kenni: | stichnot: FYI, about that ticket...a user at mythtv.dk said that he didn't get the "Video frame buffering failed too many times" error at program transitions in 0.25-fixes, but instead he got it completely randomly during the playback of LiveTV. I had not seen this behaviour before, but yesterday when I upgraded from the git tagged "0.25" to 0.25-fixes, I'm seeing the exact same thing. On my news-channel which has program-transitions every 10min, I ALW |
| [15:24:17] | kenni: | Do you still only see it on the program transitions? |
| [15:25:33] | stichnot: | kenni: yeah, I only see the problem at program transitions. What file system are you using for your live TV storage group? |
| [15:25:54] | kenni: | ext4, I can try to change the barriers if you want me to |
| [15:27:34] | stichnot: | yes please. |
| [15:31:20] | stichnot: | I'm also thinking of digging up another drive (or even a USB thumb drive), formatting it as ext3, and seeing how that works for live TV |
| [15:35:50] | bobc (bobc!~kvirc@64-126-54-49.dyn.everestkc.net) has quit (Quit: KVIrc 4.0.4 Insomnia http://www.kvirc.net/) | |
| [15:37:42] | sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Remote host closed the connection) | |
| [15:40:18] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [15:46:26] | kenni: | ok, LiveTV storage group partition has been remounted with barriers disabled and the news-channel is running on the TV. The record so far is 1,5 x news program before hitting the error (=15 minutes), so let's see how it goes now. |
| [15:50:13] | joki- (joki-!~joki@p54861A69.dip.t-dialin.net) has joined #mythtv | |
| [15:50:56] | joki (joki!~joki@p54861B03.dip.t-dialin.net) has quit (Ping timeout: 272 seconds) | |
| [15:50:56] | joki- is now known as joki | |
| [15:54:50] | cattelan_away (cattelan_away!~cattelan@c-66-41-26-220.hsd1.mn.comcast.net) has quit (Quit: Terminated with extreme prejudice - dircproxy 1.2.0) | |
| [15:57:10] | cattelan (cattelan!~cattelan@c-66-41-26-220.hsd1.mn.comcast.net) has joined #mythtv | |
| [16:11:06] | kenni: | Heh...it decided to change channel because it wanted to record something else. But it did run through a little more than two programs, which is a record. I'll turn on another frontend and leave it running for a couple of hours |
| [16:13:32] | stichnot: | kenni: try danielk22's http://code.mythtv.org/trac/attachment/ticket . . . 30-sec.patch which forces a program transition every 30 seconds (after an initial 90-second period) |
| [16:13:38] | AndyUbuntu (AndyUbuntu!~quassel@cpc1-sotn6-0-0-cust689.15-1.cable.virginmedia.com) has quit (Remote host closed the connection) | |
| [16:20:34] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [16:22:49] | kenni: | stichnot: Yes, but if that's not the root cause, a successful run with the patch doesn't prove much. Also, I don't seem to have the issue at program transitions with current 0.25-fixes – I get the error randomly during programs. |
| [16:38:52] | cocoa117 (cocoa117!~cocoa117@188-222-31-239.zone13.bethere.co.uk) has quit (Remote host closed the connection) | |
| [16:39:52] | gigem: | Captain_Murdoch: thanks. i saw the new themes late last night. |
| [16:41:19] | gigem: | xris: schedorder is simply a tie-breaker when the priorities are equal. inputid used to be the exclusvie tie-breaker. now it's schedorder then inputid. it's to avoid the need to delete and recreate cards/inpupts that sphery is all too familiar with. |
| [16:43:24] | gigem: | xris: what do you mean by "pity that back-to-back recordings cause one to get de-prioritized. multirec solved that ages ago?" nothing has changed, afaik, in that area. there is a setting which tries to avoid back-to-back programs on the same input. perhaps you changed it without realizing it. |
| [16:44:26] | gigem: | fwiw, i'm in favor of a backports branch, but only for the last major release. |
| [16:52:14] | tyuiop (tyuiop!~chatzilla@201.192.98.84.rev.sfr.net) has joined #mythtv | |
| [16:54:25] | tyuiop (tyuiop!~chatzilla@201.192.98.84.rev.sfr.net) has left #mythtv () | |
| [16:57:36] | gigem: | danielk22: what are atsc_major/minor_chan used for? i see they affect the eit scanning order. i suspect they might also be used in the channel scanner to match redetected channels with existing ones. what else? i've been seeing some inconsistent program ordering that i tracked down to the "smart" channum ordering. in my old twc setup, i used to give my clear qam channels atsc-like numbers to more easily |
| [16:57:39] | gigem: | distinguish them from the analog and hdpvr/stb channels. now, with my fios/cc setup, i just use the stb channel numbers for simplicity. because many places in mythtv non-deterministicly group by callsign/channum, i get different ordering depending on which channel, clear qsm or cc, wins out. |
| [16:59:33] | gigem (gigem!~david@mythtv/developer/gigem) has quit (Quit: WeeChat 0.3.7) | |
| [17:00:59] | gigem (gigem!~david@mythtv/developer/gigem) has joined #mythtv | |
| [17:07:11] | CaCtus491 (CaCtus491!~Kent@123-243-197-152.static.tpgi.com.au) has quit (Ping timeout: 250 seconds) | |
| [17:09:30] | sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv | |
| [17:18:01] | CaCtus491 (CaCtus491!~Kent@123-243-197-152.static.tpgi.com.au) has joined #mythtv | |
| [17:24:42] | ben1066 (ben1066!~quassel@host109-152-67-240.range109-152.btcentralplus.com) has joined #mythtv | |
| [17:26:49] | ben1066_ (ben1066_!~quassel@host86-164-181-145.range86-164.btcentralplus.com) has quit (Ping timeout: 276 seconds) | |
| [17:45:34] | CaCtus491 (CaCtus491!~Kent@123-243-197-152.static.tpgi.com.au) has quit (Ping timeout: 245 seconds) | |
| [17:51:00] | CaCtus491 (CaCtus491!~Kent@123-243-197-152.static.tpgi.com.au) has joined #mythtv | |
| [17:54:26] | kenni: | stichnot: I've just had the error twice in one hour, so it doesn't seem like disabling barriers for the LiveTV storage group makes much difference on my systems. One of them was btw at the program transition, so I'm still seeing it on at least some program transitions. |
| [17:57:54] | stoffel (stoffel!~quassel@pD9E42D7E.dip.t-dialin.net) has quit (Ping timeout: 260 seconds) | |
| [17:58:15] | ben1066 (ben1066!~quassel@host109-152-67-240.range109-152.btcentralplus.com) has quit (Changing host) | |
| [17:58:15] | ben1066 (ben1066!~quassel@unaffiliated/ben1066) has joined #mythtv | |
| [18:13:14] | sphery: | xris: adding to what gigem said, having schedorder and livetvorder means that now priority can be used for what it's meant to be used--to tell MythTV which programs you want to watch/record... i.e. "This show is X good (recording rule priority), but if you have to record off this input/channel it's not as good (so I set an input or channel priority to modify)." That allows you to say that shows recorded with your PVR-150 aren't nearly as good ... |
| [18:13:20] | sphery: | ... as those from your ClearQAM or HD-PVR or that shows on the one VHF channel in your area aren't as good since you only have a UHF antenna. |
| [18:15:29] | sphery: | And as far as the backports thing goes... I'd prefer that users who want new features just run master/unstable/development code. As it is, Mythbuntu devs are finding they have plenty of working doing all the branches they have to do for each supported Ubuntu release, so adding more would make things harder for them and other packagers (and if we have the branch, users who use packages will ask for it). |
| [18:16:37] | tgm4883: | I don't think we're willing to do multiple branches per release |
| [18:17:29] | tgm4883: | We're needing to do more testing on the packages now since we're LTS only, adding multiple branches seriously complicates things |
| [18:34:46] | danielk22: | stichnot: I'm using xfs with nobarrier. With barriers turned on applications as prosaic as firefox are unusably slow. |
| [18:38:45] | danielk22: | gigem: atsc_{major,minor}_chan are used for tuning. We use these to find the mpeg program id for a channel in the VCT table. Then the program id is used to find the PMT pid in the PAT, and the program id is used to find the correct PMT on that pid. With the PMT we find the video, audio and auxiliary content to record. |
| [18:45:01] | danielk22: | gigem: In a mixed system the smart order would probably be comparing the atsc_major_chan with channum.toUInt() and treating channels without a minor channel number as having a channel number of 0. This gives an order like this: 1,2,3,4,4–1,4–2,4–3,5–1,6,7,7–2, etc. |
| [18:45:07] | danielk22: | gigem: I don't remember the particulars of the implementation, but recall some compromises were made to make one option that 95% of people would be happy with. |
| [19:02:12] | danielk22: | sphery: I don't think backports would really be for ubuntu or other distro's. I think of it as a place we can backport somewhat risky fixes. Then we could even pull those into fixes if they turn out well. A sort of testing for fixes. It could also accept some backports that are inappropriate for fixes but are self contained enough to be easily maintain. |
| [19:02:55] | sunkan (sunkan!~sunkan@alva.zappa.cx) has quit (Quit: leaving) | |
| [19:03:43] | danielk22: | sphery: I wouldn't really consider it, except that jya has volunteered for it and he already did it unofficially for 0.24 with a decent track record. |
| [19:08:39] | xris: | gigem: re multirec.. yeah, I didn't mean to imply that had changed. scheduler has long preferred to record something later rather than things back to back on the same channel (with pre/post roll overlap). |
| [19:09:48] | xris: | sphery: I would expect that a program's recpriority would be the first/ultimate choice. given 2 shows on the same input, one with recpriority 0 and one with 5, it should record the one with 5. better yet, it should record record both on 2 inputs. in my case, only the 0 priority show was scheduled |
| [19:10:59] | xris: | I tweaked input order (or whatever the new field is) and things seem to work ok now. I think the issue was that when the new field was added (low value == good), the db migration assigned it the same value as recpriority (high value == good). |
| [19:11:14] | xris: | so it made the scheduler behave weird |
| [19:24:14] | kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has quit (Quit: kormoc) | |
| [19:35:30] | gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has quit (Read error: Connection reset by peer) | |
| [19:52:03] | gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has joined #mythtv | |
| [20:32:04] | danielk22 (danielk22!~danielk@96.57.9.142) has left #mythtv () | |
| [20:33:00] | EagleIJoe (EagleIJoe!~rockhound@31-18-129-37-dynip.superkabel.de) has joined #mythtv | |
| [20:33:08] | gigem: | danielk22: i thought we used mplexid and serviceid for tuning. anyway, that's why i asked first before "tweaking' my db to work as i want. the problem with atsc numbers, at least with clear qam on twc and fios, is the atsc channel number is for the ota channel and often doesn't match the channel number assigned by the cable co. i'll probably just hack my personal branch to do as i want since it's not a |
| [20:33:10] | gigem: | major issue. |
| [20:38:35] | skd5aner: | s/often/never |
| [20:41:54] | gigem: | xris: you're missing the point. recpriority is arbiter for what programs get scheduled first and in what order. schedorder is for cases like the following. program A is available on 5 inputs. on three of the inputs (1, 2 and 5), the total recpriority is 10 and on the other 2 inputs (3 and 4), the total recpriority is 9. the scheduler will try to schedule any showing of program A on inputs 1, 2 or 5 |
| [20:41:56] | gigem: | before considering any showing on inputs 3 or 4. okay, but which input among 1, 2 or 5 should the scheduler try first? in the past, we always used inputid so the scheduling would be deterministic. as sphery can elobarate on, the user had to delete and recreate their inputs whenever they wanted to change this tie-breaker ordering. now, schedorder is used before inputid. so, if you wanted the input |
| [20:41:58] | gigem: | ordering to be 5, 1, then 2, you set the schedorder values accordingly. if you later decide you want the order to be 1, 2, then 5, you simply change the schedorder again. |
| [20:45:25] | gigem: | skd5aner: sometimes they do match, but usually not, especially since most cablecos used high channel numbers for the hd channels. anyway, all it takes is for one to not match and mess up the channel ordering. |
| [20:46:27] | skd5aner: | gigem: I've never seen an ATSC/QAM channel num that didn't follow the #-# format... do you see simple channel numbers from your QAM scans? |
| [20:47:04] | skd5aner: | best I've ever seen is that ATSC "3–1" might match the same programing as "3" |
| [21:07:49] | stuartm: | gigem: for the second time this week a programme has been recorded twice even though the subtitle, description and programid are all identical – http://pastebin.com/ksBbMBxZ |
| [21:08:31] | stuartm: | in this instance the first copy was watched and deleted before the second recorded but it was not asked to re-record |
| [21:10:34] | stuartm: | in fact, looking at upcoming recordings it's doing it a lot, recording stuff I've told it to 'Never Record' and stuff that's been previously recorded |
| [21:15:47] | andreax1 (andreax1!~andreaz@p5089EEA8.dip.t-dialin.net) has joined #mythtv | |
| [21:17:41] | andreax (andreax!~andreaz@p54BF1D03.dip.t-dialin.net) has quit (Ping timeout: 248 seconds) | |
| [21:19:19] | stuartm: | hmm, seem to have resolved that by triggering a full resched |
| [21:39:54] | stuartm: | gigem: duplicate is 1 for the recorded episode in the above example, so it definitely wasn't supposed to schedule it to record again |
| [21:44:03] | xris: | gigem: but presuming everything except recpriority is equal, the higher recpriority should record, right? |
| [21:51:39] | xris: | I had 2 shows available on the same input, no channel priority. show recpriority is 0 and 5. the one with 0 was overriding. |
| [21:58:47] | hashbang (hashbang!~alex@213-152-35-50.dsl.eclipse.net.uk) has quit (Quit: Leaving.) | |
| [22:10:10] | clever_ is now known as clever | |
| [22:10:20] | jpabq: | stuartm, gigem, I use a lot of "power" recording rules based on actors. I see a fair amount of duplicate recordings made, and when I look at them it seems to be because the same show is matching more than one recording rule. The problem has not been great enough to complain about. I am just bringing it up now, as a point of reference. |
| [22:12:58] | knightr_: | stuartm, Hi! After doing a reset (mythfrontend -r or --reset), we should get a locale selection prompt the next time we start the frontend, right? |
| [22:21:18] | knightr_: | (we don't get one) |
| [22:23:13] | jpabq: | knightr_, does mythfrontend --prompt work? |
| [22:23:36] | knightr_: | jpabq, yes and no... |
| [22:24:32] | knightr_: | jpabq, for me it fails at the end but I want to make sure it's not something local before reporting it, I only noticed the problem when I was looking into the --reset problem... |
| [22:24:51] | knightr_: | jpabq, does it work for you? |
| [22:27:19] | knightr_: | jpabq, I had thing in my logs... MythXMLClient::GetConnectionInfo Failed – (500) |
| [22:27:26] | knightr_: | s/thing/this |
| [22:27:32] | jpabq: | Not easy for me to test right now. I will try later and let you know. |
| [22:28:22] | knightr_: | jpabq, np.... I thought you asked if it worked because it didn't work for you... |
| [22:29:56] | knightr_: | jpabq, I think people expect --reset to reset the settings and exit and get the language prompt when they start the application the next time... |
| [22:29:57] | jpabq: | No, I just knew it was another way to get the language selection prompt. |
| [22:31:15] | knightr_: | as far as I can tell it should have worked but something is preventing it to work... (my guess is the country and language are initialized using the system locale before the code that would trigger a language prompt selection is run...) |
| [22:35:18] | EagleIJoe (EagleIJoe!~rockhound@31-18-129-37-dynip.superkabel.de) has quit (Quit: EagleIJoe) | |
| [22:36:50] | knightr_: | jpabq, thank you! I guess I could ask the people who told me about the --reset problem to try the prompt to see if they have the same problem I have... |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.