| Monday, December 17th, 2012, 00:10 UTC | ||
| [00:10:47] | zombor_ (zombor_!~zombor__@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [00:23:03] | zombor_ (zombor_!~zombor__@65.29.231.135) has joined #mythtv | |
| [00:23:03] | zombor_ (zombor_!~zombor__@65.29.231.135) has quit (Changing host) | |
| [00:23:04] | zombor_ (zombor_!~zombor__@kohana/developer/zombor) has joined #mythtv | |
| [00:24:07] | stichnot: | jpabq: I ordered this one, I'll let you know how it goes: http://www.amazon.com/gp/product/B0044QMAFY/ref=ox_ya_os_product |
| [00:54:00] | jst (jst!~quassel@2620:101:8003:200:224:e8ff:fe39:34c2) has quit (Ping timeout: 246 seconds) | |
| [00:54:57] | jst (jst!~quassel@2620:101:8003:200:224:e8ff:fe39:34c2) has joined #mythtv | |
| [01:02:58] | jya: | ok… I'm going to merge back the ffmpeg resync... |
| [01:03:40] | IReboot (IReboot!~doug@CPE1caff7df6774-CM00252eac6f40.cpe.net.cable.rogers.com) has quit (Remote host closed the connection) | |
| [01:09:09] | zombor_ (zombor_!~zombor__@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [01:18:23] | Sharky-Sleep is now known as Sharky112065 | |
| [01:25:37] | stichnot: | danielk22: Why do we have both recordedseek and recordedmarkup? Is it just historical? |
| [01:29:10] | wagnerrp: | i expect it's just out of convenience, due to the sheer size of the seek data |
| [01:29:39] | wagnerrp: | there are some differences between the two tables |
| [01:30:42] | wagnerrp: | note that both will be going away as part of sphery's schema rewrite |
| [01:33:42] | stichnot: | so those and filemarkup get merged? |
| [01:34:02] | wagnerrp: | no, but shifted to two different tables |
| [01:38:32] | stichnot: | the two different tables would be something like foomarkup and fooseek? |
| [01:39:11] | wagnerrp: | indexed against a file ID rather than channel and starttime |
| [01:39:51] | wagnerrp: | markup would largely be replaced by a set of tables that records the streams in the files, and their information |
| [01:40:57] | wagnerrp: | the real difference is that __seek tracks byte location, while __markup tracks frame number |
| [01:41:46] | wagnerrp: | you could reuse the same table for both, but one or the other would be poorly optimized |
| [01:46:50] | stichnot: | ok, thanks. Mainly, I want to decide whether to write the keyframe->timecode mappings into _seek or _markup. Using _markup would save space, but involve writing to two tables instead of one during recording (if that even is an issue). |
| [01:49:54] | uglyoldbob (uglyoldbob!~quassel@24.144.55.6) has joined #mythtv | |
| [01:55:52] | stichnot: | Given that (on my system) recordedseek is vastly larger than recordedmarkup, it seems only a minor space/efficiency optimization to split them |
| [01:57:50] | skd5aner: | stichnot, dekarl: yea, the bad caps in the HD-PVR power adapter have been a known issue that hauppauge has acknowledged for years. Mine went bad too... had a NIB one, worked fine. So I called Hauppauge and they sent me a new one for free |
| [01:59:07] | skd5aner: | and jpabq ^ |
| [04:01:23] | Goga777 (Goga777!~Goga777@95-30-137-171.broadband.corbina.ru) has joined #mythtv | |
| [04:21:28] | wagnerrp: | do we have any strict limit on what characters are allowed in myth:// URIs? |
| [04:43:46] | jya: | wagnerrp: shouldn't it followed standard URIs? that is, any non-ascii character is converted to %xx |
| [04:44:27] | jya: | http://tools.ietf.org/html/rfc3986 |
| [04:44:29] | wagnerrp: | not sure, just ran into a problem a couple days ago in the file access mechanism in the python bindings |
| [04:44:49] | wagnerrp: | having a unicode filename in the myth:// URI, but it was only designed to handle ascii characters |
| [04:45:12] | jya: | "The ABNF notation defines its terminal values to be non-negative |
| [04:45:12] | jya: | integers (codepoints) based on the US-ASCII coded character set |
| [04:45:13] | jya: | [ASCII]. " |
| [04:45:40] | jya: | it should never pass unicode character, unicode character should be encoded into %encoding |
| [04:45:53] | wagnerrp: | sounds like a plan |
| [04:46:03] | wagnerrp: | thanks |
| [04:48:03] | MythBuild: | build #3270 of master-freebsd-64bit is complete: Failure [4failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/3270 blamelist: Jean-Yves Avenard <jyavenard@mythtv.org > |
| [04:49:19] | jya: | interesting… it seems that there's no standard for encoding unicode character in URI |
| [04:49:29] | MythBuild: | build #256 of master-f17–32bit is complete: Failure [4failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . t/builds/256 blamelist: Jean-Yves Avenard <jyavenard@mythtv.org > |
| [04:49:52] | wagnerrp: | complaining about qmake |
| [04:50:05] | wagnerrp: | should be 'qmake-qt4', shouldn't it? |
| [04:50:31] | jya: | probably related to cbe419a6fe58e2fd0a1425b61def5a1a811956ba |
| [04:52:33] | jya: | rhaaaaa… annoying |
| [04:53:11] | fetzerch_ (fetzerch_!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [04:54:06] | jya: | doesn't make sense |
| [04:54:09] | wagnerrp: | the build jail is still up if you need t |
| [04:54:11] | wagnerrp: | *i |
| [04:54:12] | wagnerrp: | t |
| [04:55:07] | wagnerrp: | Beirdo: you around? |
| [04:55:20] | jya: | going to have a look. |
| [04:55:21] | jya: | thanks |
| [04:55:38] | jya: | what was the ip address again? |
| [04:55:56] | wagnerrp: | wondering if it would be useful to 'cat' config.ep so there's a record of it in the build system |
| [04:56:00] | wagnerrp: | wagnerrp.com |
| [04:56:39] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 260 seconds) | |
| [05:15:01] | jya: | looks like the master-32bits need to update its qt version to 4.8 |
| [05:38:51] | MythBuild: | build #3271 of master-freebsd-64bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/3271 |
| [05:51:25] | Goga777 (Goga777!~Goga777@95-30-137-171.broadband.corbina.ru) has quit (Remote host closed the connection) | |
| [05:57:08] | MythBuild: | build #257 of master-f17–32bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . t/builds/257 |
| [06:24:12] | uglyoldbob (uglyoldbob!~quassel@24.144.55.6) has quit (Remote host closed the connection) | |
| [06:38:45] | rsiebert (rsiebert!~quassel@g226063104.adsl.alicedsl.de) has joined #mythtv | |
| [06:41:48] | rsiebert_ (rsiebert_!~quassel@g226063233.adsl.alicedsl.de) has quit (Ping timeout: 245 seconds) | |
| [07:06:17] | FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has joined #mythtv | |
| [08:06:31] | stoffel (stoffel!~quassel@pD9E41674.dip.t-dialin.net) has joined #mythtv | |
| [08:08:24] | dekarl1 (dekarl1!~dekarl@p4FCEE321.dip.t-dialin.net) has joined #mythtv | |
| [08:09:28] | dekarl (dekarl!~dekarl@p4FCEE0BC.dip.t-dialin.net) has quit (Ping timeout: 250 seconds) | |
| [08:30:05] | jya_ (jya_!~jyavenard@60.224.1.106) has joined #mythtv | |
| [08:30:07] | jya_ (jya_!~jyavenard@60.224.1.106) has quit (Changing host) | |
| [08:30:07] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [08:31:04] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Remote host closed the connection) | |
| [08:31:05] | jya_ is now known as jya | |
| [08:31:23] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [09:03:08] | Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:bc3d:4146:6d79:2ec6) has joined #mythtv | |
| [09:17:37] | bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has joined #mythtv | |
| [09:24:50] | stuarta: | jya_: the master-linux-32bit builder has been knackered since qt-4.8 became a requirement, yes it just needs an upgrade |
| [09:25:17] | jya_: | stuarta: yeah, i figured that after looking at the history of the build. |
| [09:25:24] | jya_: | what do we use that requires 4.8 ? |
| [09:26:10] | stuarta: | stuartm might have a better idea. |
| [09:28:43] | FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has quit (Ping timeout: 256 seconds) | |
| [09:30:41] | FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has joined #mythtv | |
| [09:34:38] | stuarta: | iirc, it's something todo with the required functionality works properly in qt-4–8 but needed lots of hacks on prior releases |
| [09:40:20] | Sharky112065 (Sharky112065!~Sharky112@c-24-19-57-28.hsd1.wa.comcast.net) has quit (Quit: “The only way to have a friend is to be one.” ― Ralph Waldo Emerson) | |
| [09:48:47] | Sharky112065 (Sharky112065!~Sharky112@c-24-19-57-28.hsd1.wa.comcast.net) has joined #mythtv | |
| [09:57:54] | Goga777 (Goga777!~Goga777@95-30-137-171.broadband.corbina.ru) has joined #mythtv | |
| [10:08:16] | Guest73591 (Guest73591!~quassel@75-161-183-113.mpls.qwest.net) has quit (Read error: Connection reset by peer) | |
| [10:12:25] | dekarl1 is now known as dekarl | |
| [10:35:26] | stuartm: | jya_: socket code compiles in earlier versions but doesn't actually work |
| [10:36:13] | jya_: | which socket code ? |
| [10:39:33] | jya_: | i was using Qt4.6 for a long time until moutain lion came out in July… never had issue with any of the classes using sockets... |
| [10:39:59] | stuartm: | jya_: the completely re-written stuff in master |
| [10:40:33] | jya_: | is there completely rewritten stuff? didn't know about it… need to have a look |
| [10:42:21] | stuartm: | https://github.com/MythTV/mythtv/commit/5758f14cb6 |
| [10:44:14] | jya_: | something is weird with that commit… it's just a change of mythversion.h |
| [10:46:01] | jya_: | ah it's the commit before |
| [10:48:53] | stuartm: | it's a couple of dozen commits before, being a merger |
| [10:50:06] | stuartm: | github doesn't really illustrate mergers very well |
| [10:51:38] | bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has quit (Quit: Quit) | |
| [11:47:43] | stoffel (stoffel!~quassel@pD9E41674.dip.t-dialin.net) has quit (Ping timeout: 244 seconds) | |
| [11:59:05] | dekarl: | man, I optimized EIT scanning so much that its only scanning the first channel on a multiplex now :/ |
| [11:59:13] | dekarl: | but its faster :D |
| [12:01:34] | stuarta: | hahahaha |
| [12:43:26] | xris (xris!~xris@mythtv/developer/xris) has quit (Ping timeout: 265 seconds) | |
| [12:44:54] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya) | |
| [12:44:54] | jya_ is now known as jya | |
| [12:48:28] | zombor_ (zombor_!~zombor__@kohana/developer/zombor) has joined #mythtv | |
| [12:53:47] | zombor_ is now known as zombo | |
| [12:53:48] | zombo is now known as zombor | |
| [12:57:19] | zombor (zombor!~zombor__@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [12:58:31] | IReboot (IReboot!~doug@CPE1caff7df6774-CM00252eac6f40.cpe.net.cable.rogers.com) has joined #mythtv | |
| [13:10:47] | Goga777 (Goga777!~Goga777@95-30-137-171.broadband.corbina.ru) has quit (Remote host closed the connection) | |
| [13:11:14] | stuartm: | dekarl: that's actually a great optimisation for the UK, maybe we could keep something like that for certain network+transport ids |
| [13:15:18] | stuartm: | I liked Janne's plan to have EIT operate on a duty cycle instead of permanently on, e.g. once an our grab data for all channels then go to sleep |
| [13:15:29] | stuartm: | s/our/hour/ |
| [13:23:00] | Sharky112065 is now known as Sharky-Sleep | |
| [13:23:10] | dekarl: | stuartm, I was trying to hint that the active/passive scan only captures the guide for the service that was "tuned" to, but not the other services on the same transport... So there's a mixup between "the channel that was tuned to" and "the channel the guide data is for" somewhere, haven't found it yet |
| [13:31:30] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv | |
| [13:31:38] | stuartm: | dekarl: ah |
| [13:42:00] | stuarta: | dekarl: that'll depend a lot on the broadcaster |
| [13:46:03] | danielk22: | stuarta: We should always be collecting EIT for all the channels on the same transport. Collecting data for other transports/networks would depend on the broadcaster. |
| [13:46:54] | stuarta: | again, depends entirely on the broadcaster but a single mux should at minimum give you now/next for the channels on that mux |
| [13:48:54] | dekarl: | hmm, I'm working on the lookup ONID/TSID/SID to chanid and somehow ended up dropped perfectly good data for all but on station on the floor :( |
| [13:49:32] | ** stuarta chuckles ** | |
| [13:52:19] | stuartm: | danielk22: hence why I said about keying crawler behaviour off the network/transport ids, EIT data is cross-carried on all muxes for Freeview/Freesat in the UK hence it's just a waste of time and energy to crawl through every mux |
| [13:54:42] | stuartm: | we already have a list of network/transport ids for the fixups, so they could be used to skip over muxes in the same 'network' but still visit the few muxes with FTA channels on satellite that aren't part of the Freesat lineup (not that they are worth watching) |
| [13:55:06] | stuartm: | and not that they actually carry more than a couple of hours of data |
| [13:56:37] | stuarta: | while other countries, carry only the data for that mux on the mux itself |
| [13:56:59] | stuarta: | dvb-s sometimes has an EPG channel where you go for *all* the info |
| [13:57:49] | dmfrey (dmfrey!~dmfrey@webdefence.cluster-h.websense.net) has joined #mythtv | |
| [13:58:17] | stuartm: | yeah, if we learnt which channels those were we could use the same optimisation to only visit that channel, or to weight it more than others |
| [13:58:30] | dekarl: | to make it harder we already have bugs where on dvb-s guide for one channel is transported on two muxes needing a different fixup per transmission :) |
| [13:59:17] | stuarta: | stuartm: i believe it is signalled as such, we just don't either pickup the signalling or act on it |
| [13:59:41] | stuartm: | that's of course if we want to optimise the EIT code to that extent, I'd say it was worth it for those wanting their machines to idle at low power – less crawling means less power drawn by the tuners, less writes to disc and no more full reschedules every 5 minutes |
| [13:59:42] | dekarl: | we could store the EIT data rate, or the number of different services that EIT is carried for on a mux. and the last eit update per mux (to avoid multiplexes that got updated via EITother) |
| [14:01:12] | stuartm: | dekarl: that last part is a more intelligent way of handling it than my suggestion of a hardcoded list of ids |
| [14:01:33] | stuarta: | well we implicitly prefer EITa over EITo |
| [14:45:25] | Slasher` (Slasher`!~Slasher@188.165.164.15) has quit (Remote host closed the connection) | |
| [14:55:47] | joki (joki!~joki@p54861CCE.dip.t-dialin.net) has quit (Ping timeout: 244 seconds) | |
| [14:56:47] | joki (joki!~joki@p54863C7B.dip.t-dialin.net) has joined #mythtv | |
| [15:01:16] | sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Ping timeout: 272 seconds) | |
| [15:07:16] | tonsofpcs: | ah, NIT... |
| [15:08:40] | tonsofpcs: | stuartm: is any of the TSs 'authoritative' or do they all always contain the same data? |
| [15:08:54] | stuarta: | in what context? |
| [15:08:59] | stuarta: | EIT? |
| [15:09:00] | tonsofpcs: | for the EITs |
| [15:09:07] | tonsofpcs: | for your freeview/freesat |
| [15:10:07] | stuarta: | in the uk at least the data is cross carried (ie. identical info) however it's carried in different sections depending on if it is EITa (EIT actual – ie. this mux) or EITo (EIT other – other mux) |
| [15:10:33] | stuarta: | we always prefer the EITa data over EITo, however we still fill the guide from both |
| [15:10:39] | tonsofpcs: | in the US, in theory, one station can carry the PSIP for an entire market. I think this was tested in one market and I imagine some co-owned stations in the same market may cross-PSIP (that is, put the data for both on both) but otherwise I don't think it happens. |
| [15:11:05] | stuarta: | i didn't think anyone did EIT data properly in the US |
| [15:11:42] | tonsofpcs: | stuarta: well, let's say Dave has a programming update in the next 20 minutes and they update their guide data. I imagine that the EIT on their mux must get updated, but do all of the other muxes that contain EIT for Dave get updated? |
| [15:11:57] | tonsofpcs: | stuarta: what is your definition of properly? |
| [15:12:09] | stuarta: | properly in this case = at all |
| [15:12:19] | stuarta: | or even EITa only |
| [15:12:28] | stuarta: | which is what Australia uses |
| [15:12:36] | ** tonsofpcs has 14 days of EIT + ETT in his mux... ** | |
| [15:12:41] | stuarta: | \o/ |
| [15:12:52] | tonsofpcs: | (roughly) |
| [15:12:59] | stuarta: | 14 days is good, we only get 8 days |
| [15:13:08] | zombor (zombor!~zombor__@kohana/developer/zombor) has joined #mythtv | |
| [15:13:15] | tonsofpcs: | (the way it is inserted is by number of 'tables' so it drifts a few hours each way as the tables rotate) |
| [15:13:38] | stuarta: | sounds sub optimal |
| [15:13:44] | tonsofpcs: | most receivers handle one of: "current only", "three hours", "seven days"; a few handle all 14. |
| [15:14:49] | tonsofpcs: | well, the tables shift in, so each table is n hours of programming. When that table is used up and the new one added, there's just over 14 days; when that table is 'almost done' and the new one isn't added, thre's just shy of 14. |
| [15:14:57] | tonsofpcs: | that said, any data 14 days out is highly subject to change. |
| [15:15:11] | stuarta: | sounds like how the EIT data is done |
| [15:15:15] | tonsofpcs: | most stations update their guide data from their trafficing system 2 or 3 times per day. |
| [15:15:27] | tonsofpcs: | right, it is EIT data. |
| [15:15:29] | stuarta: | it's comprised of "now/next", 0–3 days, 4–7 days |
| [15:15:49] | stuarta: | all in different tables, with different repetition rates |
| [15:15:53] | tonsofpcs: | yup. |
| [15:16:15] | tonsofpcs: | the closest repeat a lot, the furthest repeat every... 10 minutes or so? (I'd have to check) |
| [15:16:37] | tonsofpcs: | or, ya know, you could read A/53 and the like ;) |
| [15:17:38] | dekarl: | if you like you can rent some bandwidth and push out EITother for the whole market for many weeks (e.g. 8 to 12)... And why should EIT data change often? It all depends on the station. If its just showing repeats of old series plus ads for funding, why would their schedule change often? |
| [15:18:13] | dekarl: | if its a station with lots of talk shows that adjust based on world events thats a different beast. |
| [15:19:02] | tonsofpcs: | I don't know of any broadcast station here in the states that wouldn't preempt programming on something under a weeks notice. Sure, it may not happen often, but it can happen |
| [15:19:22] | tonsofpcs: | even for an 'old series' channel, it's possible that media goes missing or fails and needs to be swapped out because it can't physically be played back. |
| [15:19:45] | tonsofpcs: | that said, I need to go to work now. We have some special program to air thhat we just heard about last thursday ;) |
| [15:19:58] | dekarl: | ;) |
| [15:21:02] | tonsofpcs: | (also, I believe that even the cable 'old movie' channels update their schedules so thatthe movies being played are [or are not for tragedies] related to world events) |
| [15:22:14] | tonsofpcs: | (there was a big hoopla a few years ago when some [satirical] shows got together and were set to be showing episodes involving hurricanes at the same time – and a huge tornado took out a town and all of the networks pulled those shows) |
| [15:22:39] | dekarl: | aye, thats all correct. but the rate of change is much lower then for other stations |
| [15:23:24] | tonsofpcs: | eh. News stations rarely update their EIT as they just put "Local News" in for hour blocks and they'll just change the format of their show and brand it as-is |
| [15:23:30] | dekarl: | but in the end it all comes down to table repeatition rate / EIT bandwidth. |
| [15:24:05] | danielk22: | huh? the icc build just gained 800+ warnings but I don't see any relevant change to ./configure |
| [15:24:44] | tonsofpcs: | danielk22: remember, the guide insertion platform knnows about changes and can push changes immediately when they're made regardless of the maximum repetition rate. |
| [15:25:03] | dekarl: | out 24h public news channel has "the news" with generic episodes but updates for the talkshow topics, too |
| [15:25:49] | tonsofpcs: | talkshow topicss are probably in their traffic system and when they schedule a different show the new show's data will replace the old one. |
| [15:26:07] | tonsofpcs: | (our system would do that...) |
| [15:26:14] | dekarl: | btw, has anybody seen the EIT key/value system used in the wild? e.g. for actors or similar? NonameTV feeds it to some small cable networks, so at least some equipment can handle that. But we don't handle it in MythTV, yet |
| [15:26:31] | tonsofpcs: | key/value system? |
| [15:26:33] | dekarl: | traffic is ads, right? |
| [15:26:45] | tonsofpcs: | kinda. |
| [15:27:00] | tonsofpcs: | let me answer in detail later. send me a ping in about an hour? :) |
| [15:27:47] | dekarl: | the extended event descriptor has the long text plus it can contain a set of key/value pairs. the example in the spec is key "Cast" with value "list, of, actors, names" |
| [15:31:35] | danielk22: | there are 386 changes in configure.. they just don't show up in the github as part of the merge commit. :| |
| [15:32:20] | dekarl: | see 6.2.15 of EN 300 468 v1.13.1 at http://www.etsi.org/deliver/etsi_en/300400_30 . . . v011301p.pdf |
| [15:34:02] | dekarl: | "Text information can be structured into two columns, one giving an item description field and the other the item text. A typical application for this structure is to give a cast list, where for example the item description field might be "Producer" and the item field would give the name of the producer." |
| [15:41:14] | stuarta: | dekarl: never seen it in the wild |
| [15:51:18] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 272 seconds) | |
| [15:59:57] | tonsofpcs: | I'd have to pull the PSIP standard to look at if it's possible here... I know whe have EIT and ETT... |
| [16:01:00] | tonsofpcs: | anyway, 'traffic' is the 'librarian', responsible for tracking all media and making sure the right things get played and reporting on what got played when. |
| [16:01:44] | tonsofpcs: | so, while a 'programmer' or 'programming' will make a schedule, traffic fills it and makes it playable and containing all of the proper data and metadata ties, etc. |
| [16:02:14] | gigem: | dekarl: Since you know your way around the EIT scanner, would you mind trying to enable a scheduler related optimization? The sourceid, mplexid and maxstarttime parameters in the RescheduleMatch() call can be used to restrict the scope of the reschedule. If any of those can be used, EIT users should see a nice improvement. |
| [16:02:38] | tonsofpcs: | (in some places, the same person or persons may be doing both jobs) |
| [16:07:10] | dekarl: | tonsofpcs: ahh, that makes sense. It took me way to long to figure out that traffic logs have something to do with the schedule and ad placement. I thought it had to do with traffic jams / news for ages ;) |
| [16:08:55] | dekarl: | gigem, basically changing this call? https://github.com/MythTV/mythtv/blob/master/ . . . ner.cpp#L190 |
| [16:10:18] | superm1: | dekarl: oh that libmythhdhomerun.so destination package is unfortunate |
| [16:10:28] | superm1: | is it causing problems with 0.26 when the -dev package isn't installed? |
| [16:11:03] | dekarl: | superm1: well, you can't start the frontend due to being linked to a non-existant library |
| [16:11:18] | dekarl: | but I'm on master atm |
| [16:14:04] | tonsofpcs: | right, the ad placement part of traffic's job is getting the spots in the right place when there's a few hundred with contracts that read like "this spot needs to air after every third showing of show X and 7 times a week and 5 times each saturday" |
| [16:14:12] | superm1: | dekarl: oh – why did that error only happen in master then i wonder |
| [16:14:37] | superm1: | http://paste.ubuntu.com/1445535/ |
| [16:16:00] | gigem: | dekarl: Yes, that's the one. |
| [16:16:02] | dekarl: | likely due to https://github.com/MythTV/mythtv/commit/3c788 . . . 7b7c099ef0ab |
| [16:17:07] | dekarl: | gigem, I don't understand what maxstarttime is for. is that max(starttime) of the updated programs? |
| [16:17:24] | dekarl: | or is it max(starttime) of all relevant programs on that multiplex? |
| [16:17:36] | superm1: | dekarl: ah surely that's it. where's the soname versioning on the library now then? |
| [16:18:31] | superm1: | danielk22: is that intentional that libmythhdhomerun no longer has soname versioning appended to it with that commit? |
| [16:18:43] | gigem: | dekarl: It the max(starttime) of any programs affected. For example, if you only change program in the next 24 hours, the scheduler won't reprocess anything beyond that time. |
| [16:18:55] | danielk22: | superm1: nope, not intentional. |
| [16:19:11] | superm1: | okay so just a bug then :) |
| [16:19:16] | danielk22: | :) |
| [16:19:23] | danielk22: | thx for pointing it out |
| [16:19:27] | dekarl: | gigem, will try some variants of "in active scan mode, only reschedule when moving on to the next multiplex instead of every 60 seconds" |
| [16:20:09] | gigem: | dekarl: Great. Please let me know how big of a difference it makes. |
| [16:20:49] | dekarl: | gigem, how can I measure the difference? Reschedules per hour? |
| [16:22:39] | gigem: | dekarl: You should see a line like "Reschedule requested for MATCH 0 0 0 – SchedulerInit" and "Scheduled 312 items in 0.8 = 0.47 match + 0.05 check + 0.33 place" in your master backend log everytime the scheduler runs. |
| [16:24:21] | gigem: | In your case, the MATCH values will be what you passed to RescheduleMatch() and be labele with EITScanner instead of SchedulerInit. |
| [16:25:39] | dekarl: | ok, I have these lines in my backend log so I can just change it and collect the new vs old lines :) |
| [16:27:22] | sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv | |
| [16:37:25] | stichnot (stichnot!~stichnot@65.50.220.101) has joined #mythtv | |
| [16:37:25] | stichnot (stichnot!~stichnot@65.50.220.101) has quit (Changing host) | |
| [16:37:26] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [16:40:04] | FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has quit (Quit: FabriceMG) | |
| [16:42:19] | dekarl: | stuarta, I'd like to push the patch from http://code.mythtv.org/trac/ticket/10784 like this http://paste.ubuntu.com/1445581/ unless you have other plans. |
| [16:45:31] | toeb (toeb!~tob@HSI-KBW-37-49-118-160.hsi14.kabel-badenwuerttemberg.de) has quit (Ping timeout: 246 seconds) | |
| [16:47:02] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Remote host closed the connection) | |
| [16:48:01] | ** stuarta reads ** | |
| [16:54:22] | stuarta: | dekarl: is there any mileage in enhancing what i did earlier? ie. enhancing get_chan_id_from_db methods so that it progressively falls back to less specific matching? |
| [16:56:11] | dekarl: | both approaches are independent of eachother. For EITactive my approach skips over the ONID/TSID/SID match and only does a "service_id on this multiplex" match. For EITother its using your optimization without changes |
| [16:56:46] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv | |
| [16:59:34] | stuarta: | ah cool, i thought there was overlap. feel free to go ahead |
| [17:05:11] | MythBuild: | build #4441 of master-linux-64bit is complete: Failure [4failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/4441 blamelist: Daniel Thor Kristjansson <danielk@cuymedia.net > |
| [17:06:37] | MythBuild: | build #3274 of master-freebsd-64bit is complete: Failure [4failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/3274 blamelist: Daniel Thor Kristjansson <danielk@cuymedia.net > |
| [17:08:08] | toeb (toeb!~tob@HSI-KBW-37-49-118-160.hsi14.kabel-badenwuerttemberg.de) has joined #mythtv | |
| [17:09:12] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 252 seconds) | |
| [17:10:16] | MythBuild: | build #260 of master-f17–32bit is complete: Failure [4failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . t/builds/260 blamelist: Daniel Thor Kristjansson <danielk@cuymedia.net > |
| [17:13:45] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [17:14:47] | Chutt (Chutt!~ijr@cpe-24-29-225-175.neo.res.rr.com) has quit (Read error: Connection reset by peer) | |
| [17:16:09] | Goga777 (Goga777!~Goga777@95-30-137-171.broadband.corbina.ru) has joined #mythtv | |
| [17:16:56] | Chutt (Chutt!~ijr@cpe-24-29-225-175.neo.res.rr.com) has joined #mythtv | |
| [17:17:13] | MythBuild: | build #40 of master-linux-64bit-clang is complete: Failure [4failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . ng/builds/40 blamelist: Daniel Thor Kristjansson <danielk@cuymedia.net > |
| [17:22:01] | MythBuild: | build #4442 of master-linux-64bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/4442 |
| [17:22:05] | MythBuild: | build #462 of master-linux-64bit-icc is complete: Failure [4failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . c/builds/462 blamelist: Daniel Thor Kristjansson <danielk@cuymedia.net > |
| [17:25:08] | MythBuild: | build #3275 of master-freebsd-64bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/3275 |
| [17:29:41] | MythBuild: | build #261 of master-f17–32bit is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . t/builds/261 |
| [17:37:10] | xris (xris!~xris@xris.forevermore.net) has joined #mythtv | |
| [17:38:43] | MythBuild: | build #41 of master-linux-64bit-clang is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . ng/builds/41 |
| [17:40:47] | stichnot (stichnot!~stichnot@216.239.45.91) has joined #mythtv | |
| [17:40:48] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [17:40:48] | stichnot (stichnot!~stichnot@216.239.45.91) has quit (Changing host) | |
| [17:48:43] | MythBuild: | build #463 of master-linux-64bit-icc is complete: Success [3build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . c/builds/463 |
| [17:59:24] | stoffel (stoffel!~quassel@pD9E41C1F.dip.t-dialin.net) has joined #mythtv | |
| [17:59:30] | Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:bc3d:4146:6d79:2ec6) has quit (Read error: Connection reset by peer) | |
| [18:04:43] | petefunk (petefunk!~pfunk@198.23.147.3) has quit (Ping timeout: 245 seconds) | |
| [18:04:50] | petefunk (petefunk!~pfunk@198.23.147.3) has joined #mythtv | |
| [18:06:12] | zombor (zombor!~zombor__@kohana/developer/zombor) has quit (Ping timeout: 272 seconds) | |
| [18:11:36] | Tobbe5178 (Tobbe5178!~asdf@h186n5-sv-a13.ias.bredband.telia.com) has quit (Read error: Connection reset by peer) | |
| [18:11:41] | Goga777 (Goga777!~Goga777@95-30-137-171.broadband.corbina.ru) has quit (Remote host closed the connection) | |
| [18:15:07] | Tobbe5178 (Tobbe5178!~asdf@h186n5-sv-a13.ias.bredband.telia.com) has joined #mythtv | |
| [18:19:52] | SteveGoodey (SteveGoodey!~steve@host86-148-172-139.range86-148.btcentralplus.com) has joined #mythtv | |
| [18:46:42] | zombor (zombor!~zombor__@kohana/developer/zombor) has joined #mythtv | |
| [18:50:09] | stoffel (stoffel!~quassel@pD9E41C1F.dip.t-dialin.net) has quit (Remote host closed the connection) | |
| [18:52:34] | Mousey (Mousey!~r0dent_@ross154.net) has joined #mythtv | |
| [18:58:29] | dmfrey (dmfrey!~dmfrey@webdefence.cluster-h.websense.net) has quit (Quit: Ex-Chat) | |
| [19:36:18] | jhezer_ (jhezer_!~jon@c-98-226-220-178.hsd1.il.comcast.net) has joined #mythtv | |
| [19:39:42] | zombor (zombor!~zombor__@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [19:40:14] | zombor (zombor!~zombor__@50-73-122-41-ip-static.hfc.comcastbusiness.net) has joined #mythtv | |
| [19:40:14] | zombor (zombor!~zombor__@50-73-122-41-ip-static.hfc.comcastbusiness.net) has quit (Changing host) | |
| [19:40:15] | zombor (zombor!~zombor__@kohana/developer/zombor) has joined #mythtv | |
| [19:40:48] | kth (kth!~kth@unaffiliated/kth) has joined #mythtv | |
| [20:07:36] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [20:25:32] | dzen (dzen!~benoit@kimsufi.litchis.org) has joined #mythtv | |
| [20:25:40] | gigem (gigem!~david@mythtv/developer/gigem) has quit (Quit: WeeChat 0.3.8) | |
| [20:25:47] | dzen: | hello there |
| [20:27:40] | gigem (gigem!~david@pool-71-123-128-124.dllstx.fios.verizon.net) has joined #mythtv | |
| [20:27:40] | gigem (gigem!~david@pool-71-123-128-124.dllstx.fios.verizon.net) has quit (Changing host) | |
| [20:27:40] | gigem (gigem!~david@mythtv/developer/gigem) has joined #mythtv | |
| [20:28:04] | jhezer_ (jhezer_!~jon@c-98-226-220-178.hsd1.il.comcast.net) has quit (Ping timeout: 272 seconds) | |
| [20:33:44] | dekarl: | Hmm, the EITScanner is storing updated events to a container and later writes it back to the database. Will the scheduler see any of the changes while they are not written to the database, yet? |
| [20:37:01] | stuartm: | no |
| [20:47:53] | dekarl: | Hmm, that was a red herring, was looking at the event cache (EITCache) but thinking of the updated programs derived from these events (db_events). |
| [20:56:57] | dzen: | Seems I broke my storage group |
| [20:57:35] | dzen: | I got a lot of 'GetPlaybackURL '1002_timestamp.mpg' should be local, but it cannot be found |
| [20:58:20] | dzen: | an a lot of 'GetPlaybackURL/UNABLE/TO/FIND/FILE/ON/<machine>/file.mpg' |
| [20:58:33] | dzen: | I didn't saw anything interesting on google |
| [20:58:35] | dzen: | any hint ? |
| [21:08:52] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit (Read error: Connection reset by peer) | |
| [21:10:10] | dekarl: | dzen: do you notice good recordings vanishing or is that recordings failing to actualy record in the first place? |
| [21:10:34] | dzen: | seems the first file is ok, but not the following |
| [21:10:47] | dekarl: | you can try "find / -name 1002_timestamp.mpg" and check if the recording is still on the disk somewhere |
| [21:10:49] | dzen: | If I understand correctly, mythtv records files one by one |
| [21:11:01] | dzen: | file is not there :/ |
| [21:11:21] | dzen: | streaming to xbmc stops right after 1 or 2 minutes |
| [21:11:33] | dekarl: | btw, you likely want #mythtv-users ;) |
| [21:11:43] | dzen: | okay :) thks for the hint :) |
| [21:12:10] | dzen: | sorry for the noise here |
| [21:12:11] | dzen (dzen!~benoit@kimsufi.litchis.org) has left #mythtv () | |
| [21:14:27] | len_ (len_!~quassel@75-161-183-113.mpls.qwest.net) has joined #mythtv | |
| [21:14:47] | zombor_ (zombor_!~zombor__@50-73-122-41-ip-static.hfc.comcastbusiness.net) has joined #mythtv | |
| [21:14:48] | zombor_ (zombor_!~zombor__@50-73-122-41-ip-static.hfc.comcastbusiness.net) has quit (Changing host) | |
| [21:14:48] | zombor_ (zombor_!~zombor__@kohana/developer/zombor) has joined #mythtv | |
| [21:18:48] | zombor (zombor!~zombor__@kohana/developer/zombor) has quit (Ping timeout: 264 seconds) | |
| [21:21:14] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv | |
| [21:50:08] | zombor_ (zombor_!~zombor__@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [21:52:33] | SteveGoodey (SteveGoodey!~steve@host86-148-172-139.range86-148.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [22:14:16] | zombor (zombor!~zombor__@50-73-122-41-ip-static.hfc.comcastbusiness.net) has joined #mythtv | |
| [22:14:17] | zombor (zombor!~zombor__@50-73-122-41-ip-static.hfc.comcastbusiness.net) has quit (Changing host) | |
| [22:14:17] | zombor (zombor!~zombor__@kohana/developer/zombor) has joined #mythtv | |
| [22:14:27] | zombor (zombor!~zombor__@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [22:32:54] | stuartm: | It can't be right, but look at the LOC for MythTV compared to everything else, including the kernel – http://scan.coverity.com/all-projects.html |
| [22:32:55] | stuartm: | heh |
| [22:33:22] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit (Read error: Connection reset by peer) | |
| [22:34:17] | stuartm: | ohloh reckons it's just 2,885,170 |
| [22:34:39] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv | |
| [22:37:53] | kormoc: | you can filter 3rd party libs out of ohloh to keep the count realistic |
| [22:41:24] | stuartm: | kormoc: that's new then, I asked them to add that at least two years ago |
| [22:43:43] | stuartm: | kormoc: any pointers to a guide? |
| [22:44:31] | stuartm: | n/m, found it |
| [22:46:59] | stuartm: | ignoring external and contrib for now |
| [22:47:51] | stuartm: | that's going to make for some interesting stats, it'll appear the project went on a crash diet |
| [22:50:58] | jst (jst!~quassel@2620:101:8003:200:224:e8ff:fe39:34c2) has quit (Remote host closed the connection) | |
| [22:51:10] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit (Quit: Why does windows NFS server cause a freaking BSD...) | |
| [22:53:32] | kormoc: | heh, yeah |
| [22:53:48] | jst (jst!~quassel@2620:101:8003:200:224:e8ff:fe39:34c2) has joined #mythtv | |
| [22:57:42] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 264 seconds) | |
| [22:59:48] | jya: | danielk22: I could have sworn I had made sure that the icc change carried over the configure update. I clearly remember going over it a few times and manually restoring it :( |
| [23:07:06] | kth (kth!~kth@unaffiliated/kth) has quit (Quit: Leaving.) | |
| [23:12:18] | stichnot: | My sql-fu is not powerful enough to understand load_markup_datum() in programinfo.cpp. Is it really taking the average of values in the markup table? Is it a weighted average? |
| [23:13:17] | stichnot: | and imo, all the callers of that function are using it in a silly way at best, blatantly incorrect at worst |
| [23:17:19] | stuartm: | from memory it's calculating stuff like the the most frequently sampled resolution, not an average but the value most likely to represent the content as opposed to the adverts etc |
| [23:19:11] | kormoc: | stichnot: I wrote that, it's as stuartm said, it's calculating based on the one with the highest amount of runtime |
| [23:19:46] | stichnot: | oh, so the comment about "average" is misleading? |
| [23:20:18] | kormoc: | Yes, it's not an average, it's a ordered sum with a limit of 1 |
| [23:21:41] | stichnot: | TVRec::FinishedRecording() calls QueryAverageHeight() and if the result is >1000 it classifies the recording as 1080. I guess that's more of an error tolerance than looking at the average. |
| [23:22:12] | stichnot: | (a recording that is 75% 1080i and 25% 720p ads would work out to average height of 990...) |
| [23:22:45] | kormoc: | yeah, there was reason behind that, as if some reason 1080 shows were being reported at 10somethingelseclosebutnot quite |
| [23:23:09] | stichnot: | ok, that makes sense. |
| [23:23:59] | stichnot: | But QueryTotalDuration() and QueryTotalFrames() are a little interesting, as one would expect only one mark of the corresponding type to be associated with a recording. |
| [23:24:07] | stuartm: | not everything that is technically full HD is actually 1080, e.g. films shown in their original aspect ratio |
| [23:25:05] | stuartm: | although that particular cutoff doesn't really account for those |
| [23:25:38] | kormoc: | stichnot: nah, it's how many frames in-between the marks, so you have to sum them, and it's a helper query to do so (just overly complex) iirc |
| [23:29:32] | stichnot: | kormoc: what I meant was that for almost all of the MarkTypes, it's expected that there may be more than one mark of that type in the recording. That's not really true of the last values, MARK_DURATION_MS and MARK_TOTAL_FRAMES. If e.g. a recording has more than one MARK_DURATION_MS mark, then QueryTotalDuration() won't return the recording's duration. |
| [23:29:52] | kormoc: | ooh, I see |
| [23:29:57] | kormoc: | that's true |
| [23:31:05] | stichnot: | For those two functions, I think we really want a different query that returns the max value. |
| [23:31:24] | kormoc: | or the last value |
| [23:31:27] | stichnot: | assuming there is ever the possibility of having multiple marks of that type |
| [23:32:21] | stichnot: | kormoc: you're right, I mean the data associated with the highest mark |
| [23:34:58] | taylorr: | jya: do you have a diff anywhere of the changes between our ffmpeg and the original? |
| [23:35:02] | stichnot: | and in case it's not clear from my musings here over the last several days, I'm interested in pre-calculating durations or time offsets for each keyframe, taking into account the latest framerate, repeat_pict flags, etc., without breaking any existing assumptions. |
| [23:40:12] | sl1ce (sl1ce!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has quit (Quit: Konversation terminated!) | |
| [23:41:29] | sl1ce (sl1ce!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has joined #mythtv | |
| [23:59:09] | jya: | taylorr: quite easy to get: diff -Nau path_to_ffmpeg/configure path_to_mythtv/configure |
| [23:59:20] | jya: | unfortunately, it's a very manually intensive labor |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.