| Monday, March 19th, 2012, 00:03 UTC | ||
| [00:03:44] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 244 seconds) | |
| [00:16:44] | dblain: | danielk22: You're probably right... seems like a good place to use a reference counted instance. Will have to take a look at it for 0.26. |
| [00:20:27] | MythBuild: | build #2191 of master-linux-ppc is complete: Failure [failed compile core] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/2191 blamelist: Nicolas Riendeau <nriendeau@mythtv.org > |
| [00:27:03] | jafa (jafa!~jafa@c-98-234-217-27.hsd1.ca.comcast.net) has joined #mythtv | |
| [00:30:56] | knightr_: | what the? |
| [00:31:15] | knightr_: | /usr/bin/ld: BFD (GNU Binutils for Debian) 2.21.53.20110910 internal error, aborting at ../../bfd/merge.c line 877 in _bfd_merged_section_offset |
| [00:50:35] | [TheAsp] ([TheAsp]!~asp@blk-222-139-8.eastlink.ca) has quit (Read error: Connection reset by peer) | |
| [01:22:50] | bcgrown (bcgrown!45ac9ceb@gateway/web/freenode/ip.69.172.156.235) has quit (Quit: Page closed) | |
| [01:42:06] | deansouth8 (deansouth8!4ac7342b@gateway/web/freenode/ip.74.199.52.43) has quit (Ping timeout: 245 seconds) | |
| [01:46:17] | xris: | grumble. looking less and less likely that SD can ever get nonprofit status |
| [02:03:39] | MythBuild: | build #2192 of master-linux-ppc is complete: Success [build successful] Build details are at http://code.mythtv.org/buildbot/builders/mast . . . /builds/2192 |
| [02:39:55] | cesman (cesman!~cesman@pdpc/supporter/professional/cesman) has quit (Quit: Konversation terminated!) | |
| [04:09:29] | saintdev (saintdev!~saint@unaffiliated/saintdev) has left #mythtv ("Leaving") | |
| [04:31:25] | jafa: | hi guys |
| [04:32:01] | jafa: | we have a internal beta firmware for HDHomeRun units to support tuning by virtual channel number |
| [04:33:09] | jafa: | once the unit has been programmed with the channel list it means mythtv could tune by virtual channel number for antenna or clear-qam cable sources |
| [04:34:02] | jafa: | which means we could avoid the MythTV channel scan and US ClearQAM naming issues |
| [04:34:50] | wagnerrp: | with the virtual channel numbers pushed downstream by Silicon Dust? |
| [04:36:43] | jafa: | current working firmware requires a local machine to set the mapping list but longer term would like to make it automatic if you opt-in to syncing with our lineup server |
| [04:37:13] | jafa: | you can pull the list of channels from the device as well – same as the CableCARD model |
| [04:37:42] | jafa: | HDHomeRUn Prime – http://<ip addr>/lineup.xml |
| [04:39:38] | jafa: | plan is to make the feature available for all models via a firmware upgrade |
| [04:42:10] | wagnerrp: | i know Robert Kulagowski as been working on setting up some similar mechanism through Schedules Direct |
| [04:42:17] | wagnerrp: | but last i heard anything about it was several months ago |
| [04:42:44] | wagnerrp: | and was write only, requiring users to email him the output of some perl script, that grabbed channel listings from the mythtv database |
| [04:50:27] | knightr_: | If RC hasn't been cut, could any dev review this? http://www.pastebin.ca/2129799 |
| [04:59:38] | wagnerrp: | looks fine to me, assuming theres a pressing need for directory -> folder |
| [05:00:06] | wagnerrp: | although i would question lines 178 and 190 |
| [05:00:36] | wagnerrp: | largely because including dashes as filler in a GUI just seems... wrong... somehow |
| [05:02:00] | knightr_: | thank you Raymond, some of those sentences actually caused confusion for translators, easiest fix was directory -> folder... |
| [05:02:41] | wagnerrp: | i saw discussion about it earlier tonight, but i didnt read through it |
| [05:03:10] | knightr_: | I can't make the call for these two lines, I just added the tr()... beird o would have to decide about changing those.... |
| [05:05:35] | knightr_: | so does as far as the code is concerned, do I have you OK to commit? |
| [05:05:41] | knightr_: | s/does// |
| [05:06:40] | ** knightr_ needs sleep... the longer I stay awake the more I make mistakes... ** | |
| [05:08:56] | wagnerrp: | code looks fine, although i would ping Beirdo directly |
| [05:09:08] | wagnerrp: | he tagged the beta, so chances are hes doing the rc as well |
| [05:13:41] | knightr_: | wagnerrp, Thank you and if we don't talk again tonight, good night! |
| [05:15:05] | knightr_: | Beirdo, are you currently doing the RC? If it's not too late I would commit that direcrtory -> folder fix, if it's too late however, no problem, I'll commit it post 0.25 release... |
| [05:15:15] | Beirdo: | it would be in just under 2h |
| [05:15:28] | Beirdo: | there's time for strings :) |
| [05:16:36] | knightr_: | OK, I'm committing it and correcting the indent of one of my previous commit, I just realized that I went past 80 columns.. |
| [05:17:04] | knightr_: | Thank you! |
| [05:21:09] | Beirdo: | coolio |
| [05:21:11] | Beirdo: | no prob |
| [05:45:21] | knightr_: | Beirdo, done, thank you! Geez, 80 columns is not wide, I actually had to fix two commits... I'm waaaay too used to having more than 80 columns... Good night! |
| [05:51:04] | Beirdo: | cool |
| [06:02:33] | superm1: | Beirdo: is the 0.25 rc going to be the sort of thing that if no other problems it turns into release, or just that it's "really close to release and there will certainly be some fixes before declaring 0.25"? |
| [06:08:11] | Beirdo: | I expect it to be closer to the latter. It all depends on how many bugs are reported and fixed, I guess |
| [06:08:54] | Beirdo: | unless people misbehave, the only changes from rc to final should be translations and bug fixes |
| [06:09:40] | Beirdo: | now if a HUGE bug fix is found, there's always a possibility we'd want to delay final to allow the bug fix to soak in |
| [06:09:52] | Beirdo: | make sense? |
| [06:10:40] | superm1: | okay yeah that makes sense |
| [06:10:56] | superm1: | just some projects will actually just rename tarballs and stuff to final release etc |
| [06:10:58] | superm1: | so wasn't sure |
| [06:11:33] | Beirdo: | that is a possibility, but I think there will be enough misc bugs left to prevent that this time around |
| [06:11:49] | Beirdo: | let alone translation changes now that strings will be frozen |
| [06:11:52] | superm1: | ok |
| [06:25:00] | kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has quit (Quit: kormoc) | |
| [06:38:01] | mattiasl (mattiasl!c210d812@gateway/web/freenode/ip.194.16.216.18) has joined #mythtv | |
| [06:58:00] | xris: | Beirdo: if you haven't tagged yet, don't forget to put the dash back in |
| [07:04:55] | Beirdo: | yeah |
| [07:14:24] | stichnot (stichnot!chatzilla@mythtv/developer/stichnot) has quit (Ping timeout: 260 seconds) | |
| [07:23:21] | Beirdo: | done |
| [07:41:23] | joki (joki!~joki@p548645CC.dip.t-dialin.net) has quit (Ping timeout: 244 seconds) | |
| [08:16:03] | joki (joki!~joki@p54865172.dip.t-dialin.net) has joined #mythtv | |
| [08:37:32] | mattiasl (mattiasl!c210d812@gateway/web/freenode/ip.194.16.216.18) has quit (Quit: Page closed) | |
| [08:38:13] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya) | |
| [09:05:53] | stuartm: | sphery: I never tried it with mythui, only the KDE character selector |
| [09:06:35] | stuartm: | oh, wait I did try it with mythui, heh |
| [09:25:52] | map7 (map7!~map7@ppp118-209-23-41.lns20.mel4.internode.on.net) has joined #mythtv | |
| [09:28:28] | knightr (knightr!~knightr@mythtv/developer/knightr) has joined #mythtv | |
| [09:29:15] | stuarta: | i thought we had a fix for the issue post jim's speedup patch? |
| [09:29:25] | stuarta: | yet it's still been reverted?? |
| [09:30:19] | knightr_ (knightr_!~knightr@69-165-170-178.dsl.teksavvy.com) has quit (Ping timeout: 260 seconds) | |
| [09:35:31] | map7 (map7!~map7@ppp118-209-23-41.lns20.mel4.internode.on.net) has quit (Ping timeout: 264 seconds) | |
| [09:42:25] | markk (markk!~mark@host86-177-172-64.range86-177.btcentralplus.com) has joined #mythtv | |
| [09:42:41] | markk (markk!~mark@host86-177-172-64.range86-177.btcentralplus.com) has left #mythtv () | |
| [09:48:42] | xavierh (xavierh!~xavier@cpc1-swin3-0-0-cust274.3-1.cable.virginmedia.com) has joined #mythtv | |
| [09:55:18] | pclark (pclark!~pclark@193.35.11.116) has joined #mythtv | |
| [10:05:02] | mike|3 (mike|3!~mike@c-76-115-119-121.hsd1.or.comcast.net) has quit (Remote host closed the connection) | |
| [10:05:53] | mike|2 (mike|2!~mike@c-76-115-119-121.hsd1.or.comcast.net) has joined #mythtv | |
| [10:34:37] | stuartm: | decision was taken to wait since there may have been other unforeseen regressions, it will be backported to 0.25-fixes after a period in 0.26 |
| [10:36:20] | pclark_ (pclark_!~pclark@193.35.8.5) has joined #mythtv | |
| [10:39:16] | pclark (pclark!~pclark@193.35.11.116) has quit (Ping timeout: 276 seconds) | |
| [10:46:05] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [10:59:41] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [11:26:29] | markk (markk!~mark@host86-177-172-64.range86-177.btcentralplus.com) has joined #mythtv | |
| [11:26:45] | markk (markk!~mark@host86-177-172-64.range86-177.btcentralplus.com) has left #mythtv () | |
| [11:31:24] | pclark_ (pclark_!~pclark@193.35.8.5) has quit (Remote host closed the connection) | |
| [11:35:34] | pclark (pclark!~pclark@193.35.8.5) has joined #mythtv | |
| [11:47:19] | knightr__ (knightr__!~knightr@69-165-170-178.dsl.teksavvy.com) has joined #mythtv | |
| [11:52:59] | knightr (knightr!~knightr@mythtv/developer/knightr) has quit (Quit: Leaving) | |
| [11:53:00] | knightr__ (knightr__!~knightr@69-165-170-178.dsl.teksavvy.com) has quit (Quit: Leaving) | |
| [11:53:15] | knightr (knightr!~knightr@mythtv/developer/knightr) has joined #mythtv | |
| [11:55:58] | pclark (pclark!~pclark@193.35.8.5) has quit (Remote host closed the connection) | |
| [12:15:22] | knightr (knightr!~knightr@mythtv/developer/knightr) has quit (Read error: Connection reset by peer) | |
| [12:15:44] | knightr (knightr!~knightr@mythtv/developer/knightr) has joined #mythtv | |
| [12:17:57] | nukenn (nukenn!~nukenn@open.integrada.coop.br) has joined #mythtv | |
| [12:18:01] | nukenn: | hi all |
| [12:18:08] | nukenn: | is mythtv compatible with DLNA }? |
| [12:18:18] | nukenn: | i knwo that it have Upnp |
| [12:18:25] | nukenn: | it's the same thing ? |
| [12:21:02] | Anduin (Anduin!~awithers@pdpc/supporter/professional/anduin) has joined #mythtv | |
| [12:30:25] | peitolm: | nukenn: see topic, that's a -users question |
| [12:35:05] | pclark (pclark!~pclark@193.35.11.116) has joined #mythtv | |
| [12:38:24] | j-rod|afk is now known as j-rod | |
| [13:21:23] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [13:25:54] | stichnot (stichnot!chatzilla@nat/intel/x-lrucgnlrczrhvdnv) has joined #mythtv | |
| [13:25:54] | stichnot (stichnot!chatzilla@nat/intel/x-lrucgnlrczrhvdnv) has quit (Changing host) | |
| [13:25:55] | stichnot (stichnot!chatzilla@mythtv/developer/stichnot) has joined #mythtv | |
| [13:27:27] | jpabq_ (jpabq_!~jpabq@mythtv/developer/jpabq) has joined #mythtv | |
| [13:28:18] | jpabq_ (jpabq_!~jpabq@mythtv/developer/jpabq) has quit (Client Quit) | |
| [13:34:15] | pclark_ (pclark_!~pclark@193.35.11.125) has joined #mythtv | |
| [13:34:46] | pclark (pclark!~pclark@193.35.11.116) has quit (Ping timeout: 276 seconds) | |
| [13:36:12] | stuartm: | nukenn: it costs thouands of dollars just to see the DLNA spec under a non-disclosure agreement, so no open source project can honestly claim DLNA compatibility |
| [13:41:14] | stuartm: | that said, it seems libdlna claims to be based on the official spec, so I'm not sure how much of what I just said is true ... |
| [13:44:26] | nukenn: | huum ok |
| [13:46:45] | nukenn (nukenn!~nukenn@open.integrada.coop.br) has quit (Read error: Connection reset by peer) | |
| [13:47:02] | nukenn (nukenn!~nukenn@open.integrada.coop.br) has joined #mythtv | |
| [13:49:33] | xavierh: | why is there area and buttonarea in buttinlist ? |
| [13:49:39] | xavierh: | buttonlist |
| [13:56:24] | stuartm: | xavierh: the total area includes the arrows, the buttonarea defines the sub-area which can be used for the buttons |
| [13:57:42] | stuartm: | it also appears that DLNA includes a copy protection requirement, so a DLNA certified media renderer would have to support DRM which is technically impossible for an open source |
| [13:58:14] | stuartm: | nukenn: all that said, there is upnp support in MythTV |
| [13:59:03] | stuartm: | xavierh: and in 0.25, there is also the optional scrollbar which you don't want the buttons overlapping |
| [14:01:04] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv | |
| [14:01:15] | danielk22: | stuartm: You can see many DLNA specs without an NDA or being a member. But we can't claim to be DLNA certified. Nor would it really be true to say we're even DLNA compatible. Our UPnP support allows many DLNA devices to work with MythTV that's about the extent of it. |
| [14:03:16] | stichnot: | stuartm: danielk22: Will I run into any problems if the pbb has a helper thread running in the background that lazily generates the buttonlist item strings each time the buttonlist is recreated? |
| [14:03:57] | stichnot: | I'm wondering about bad interactions with the UI thread |
| [14:05:56] | xavierh: | stuartm: ok, thx |
| [14:07:22] | seeker (seeker!~seeker@unaffiliated/seeker) has joined #mythtv | |
| [14:08:26] | stuartm: | so long as you don't touch MythButtonListItem or anything from libmythui in that thread you'll be fine, i.e. restrict it to generating the InfoMap and then send an event back to the UI thread with the map where it can be assigned to the button item |
| [14:10:27] | Jordack-isCool (Jordack-isCool!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv | |
| [14:11:32] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit (Ping timeout: 246 seconds) | |
| [14:15:54] | stichnot: | I see, thanks. |
| [14:23:38] | knightr_ (knightr_!~knightr@69-165-170-178.dsl.teksavvy.com) has joined #mythtv | |
| [14:26:49] | knightr__ (knightr__!~knightr@69-165-170-178.dsl.teksavvy.com) has joined #mythtv | |
| [14:27:20] | knightr (knightr!~knightr@mythtv/developer/knightr) has quit (Ping timeout: 265 seconds) | |
| [14:30:08] | knightr_ (knightr_!~knightr@69-165-170-178.dsl.teksavvy.com) has quit (Ping timeout: 252 seconds) | |
| [14:39:51] | danielk22: | stichnot: what stuartm said. :) The UI is not thread-safe, but you can send the results generated in another thread to the UI thread via an event. There are a few examples of this in the PBB and PBBHelper interaction. |
| [14:41:56] | stuartm: | it would need to be aware of program info UPDATE events, you don't want to be overwriting new information with old |
| [14:52:53] | mike|3 (mike|3!~mike@c-76-115-119-121.hsd1.or.comcast.net) has joined #mythtv | |
| [14:55:55] | mike|2 (mike|2!~mike@c-76-115-119-121.hsd1.or.comcast.net) has quit (Ping timeout: 264 seconds) | |
| [14:59:34] | pclark_ (pclark_!~pclark@193.35.11.125) has quit (Remote host closed the connection) | |
| [15:00:19] | pclark (pclark!~pclark@193.35.11.125) has joined #mythtv | |
| [15:01:11] | stichnot (stichnot!chatzilla@mythtv/developer/stichnot) has quit (Ping timeout: 255 seconds) | |
| [15:03:59] | pclark (pclark!~pclark@193.35.11.125) has quit (Remote host closed the connection) | |
| [15:14:32] | Jordack-isCool is now known as Jordack | |
| [15:23:52] | Chutt_ is now known as Chutt | |
| [15:29:36] | j-rod is now known as j-rod|afk | |
| [15:50:39] | cesman (cesman!~cesman@pool-173-51-174-58.lsanca.fios.verizon.net) has joined #mythtv | |
| [15:50:40] | cesman (cesman!~cesman@pool-173-51-174-58.lsanca.fios.verizon.net) has quit (Changing host) | |
| [15:50:40] | cesman (cesman!~cesman@pdpc/supporter/professional/cesman) has joined #mythtv | |
| [16:06:20] | gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has quit (Read error: Connection reset by peer) | |
| [16:06:56] | nukenn (nukenn!~nukenn@open.integrada.coop.br) has quit (Read error: Connection timed out) | |
| [16:07:32] | nukenn (nukenn!~nukenn@open.integrada.coop.br) has joined #mythtv | |
| [16:13:23] | stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has joined #mythtv | |
| [16:17:31] | stichnot: | danielk22: about the UI not being thread-safe. My intention would have been to use a lock to guard the conversion from ProgramInfo into button list item properties. That piece is short-duration and non-blocking. Is that verboten? |
| [16:18:48] | stichnot: | stuartm: with such locking, the helper thread would detect if the button list item was already initialized and do nothing in that case. Seems like listening for UPDATE events would be unnecessary in that case. |
| [16:21:38] | stichnot: | At a higher level, there's the argument that a helper thread shouldn't be necessary given the minimal time to generate one page worth of button list items, and this is an opportunity to tune the MythUI implementation. Thoughts on that? |
| [16:21:44] | gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has joined #mythtv | |
| [16:24:40] | stichnot: | A counter-argument there is the issue of incremental search over a button list |
| [16:29:16] | stuartm: | one mark against github's code browser is that you can't toggle between a file as it appears in master and 0.24-fixes, you have to switch branches and dig through the tree again :( |
| [16:30:04] | stuartm: | oh, actually you can, I was looking in the wrong place |
| [16:33:36] | gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has quit (Quit: Leaving) | |
| [16:40:50] | stichnot: | bummer — I was hoping #10474 would fix this barrage of errors I always get on CBS programs: "E Decoder avformatdecoder.cpp:3392 (ProcessDVBDataPacket) AFD: VBI: Unknown descriptor: 153" |
| [16:41:16] | stuarta: | that's easy enough to fix |
| [16:41:26] | stuarta: | stub that descriptor |
| [16:42:00] | stuartm: | 10474 was for ac3 audio in mpeg-ts, not vbi |
| [16:43:14] | stichnot: | was still hoping :) |
| [16:43:59] | j-rod|afk is now known as j-rod | |
| [16:44:36] | stuartm: | Beirdo: feel like updating cppcheck again? see what additional stuff we get and might fix before the release? |
| [16:44:40] | stichnot: | I get tons of alternating descriptor message for 153 and 1, with an occasional 224 and 241 thrown in for good measure |
| [16:45:18] | stuartm: | danielk22 might know what those are supposed to be |
| [16:45:25] | stichnot: | so it would be better to get a deeper understanding of the issue before just stubbing it out, I think |
| [16:46:17] | stuarta: | it'll be in one of the spec's |
| [16:46:42] | stuarta: | what i mean by stub out. is add support for it, but without any actual useful functions in it |
| [16:46:54] | stuarta: | there are quite a few of these in the descriptors already |
| [16:47:13] | stuarta: | it clears up the "unknown descriptor" issue and allows proper support to be added later |
| [16:48:15] | stichnot: | stuarta: I see |
| [16:51:39] | stuarta: | 0x99 (153) is missing, as is 0xE0 (224), 0xF1 (241) |
| [16:52:47] | stichnot: | Does it even make sense for DVB VBI packets being present in U.S. ATSC broadcasts? |
| [16:53:07] | kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has joined #mythtv | |
| [16:53:23] | stuarta: | if it's part of the mpeg spec rather than specifically atsc or dvb then es |
| [16:53:25] | stuarta: | ye |
| [16:53:27] | stuarta: | yes |
| [16:54:45] | stuarta: | but potentially it's something specific to the broadcaster |
| [16:55:12] | javatexan (javatexan!~Adium@129.62.151.124) has joined #mythtv | |
| [16:56:39] | seeker (seeker!~seeker@unaffiliated/seeker) has quit (Quit: Colloquy for iPhone - http://colloquy.mobi) | |
| [16:57:17] | zombor_ (zombor_!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [16:58:38] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Ping timeout: 240 seconds) | |
| [16:59:12] | seeker (seeker!~seeker@unaffiliated/seeker) has joined #mythtv | |
| [16:59:13] | stichnot: | I guess I assumed that DVB meant non-U.S. and it would be unthinkable for a U.S. broadcaster to be thinking of anything non-U.S., but I could be wrong |
| [16:59:37] | sphery: | stichnot: In my not-an-expert-in-mythui opinion, we should move as much processing as possible outside of the main UI thread, since the only thing it does there is slow down the UI/responsiveness and cause problems. So, the best solution for "takes a long time to generate the information to display" code is to background it--just like was done for the preview generation/setting. |
| [17:00:04] | stichnot: | sphery: makes sense. |
| [17:01:23] | stichnot: | also, there's always the pattern that innocently enough you add a lock around something that is short and non-blocking, then 2 years down the road something long and/or blocking creeps in |
| [17:01:37] | stichnot: | and there are no tools to detect/enforce this |
| [17:02:15] | sphery: | Oh, and I should admit I'm looking at it from a "generate the InfoMap as a whole" perspective, not just from the "slice and dice the symptom into unnoticeable chunks" generate-InfoMap-for-this-screen. Since the whole process takes time, starting a background thread to do it gives the best of both worlds--we can generate it all for best responsiveness when scrolling/changing display and do so without affecting first-display time. |
| [17:04:07] | sphery: | and, yeah, I don't know of any tools to help with the "this must be a fast section of code" stuff--especially since fast is often relative and system dependent. :( |
| [17:04:57] | Beirdo: | stuartm: will do :) |
| [17:05:10] | stichnot: | sphery: if I'm parsing that right, you're saying you're in favor of the background thread? |
| [17:05:23] | sphery: | yeah |
| [17:06:12] | sphery: | but ideally a background thread that computes the values for all recordings so they're there for scrolling--not just computes the ones currently displayed |
| [17:09:00] | stichnot: | right, that was my idea, and it has the side effect of filling in all the incrementally searchable data |
| [17:10:44] | Beirdo: | MythBuild force build cppcheck-master now |
| [17:10:55] | Beirdo: | MythBuild: force build cppcheck-master now |
| [17:10:56] | MythBuild: | build forced [ETA 13m16s] |
| [17:10:56] | MythBuild: | I'll give a shout when the build finishes |
| [17:10:59] | Beirdo: | stupid bot |
| [17:11:14] | stuarta: | finishes or breaks, whichever occurs first |
| [17:13:06] | Beirdo: | heh |
| [17:15:19] | joki (joki!~joki@p54865172.dip.t-dialin.net) has quit (Quit: c ya!) | |
| [17:16:04] | stuartm: | sphery, stichnot: there is a tipping point where moving more and more things into the background makes the code so horribly complicated that it outweighs the benefits |
| [17:17:12] | stuarta: | but then if you made the ui thread do ui and thats it, and everything else done by a worker thread(s) then it simplifies it again! |
| [17:17:20] | joki (joki!~joki@p54865172.dip.t-dialin.net) has joined #mythtv | |
| [17:17:42] | stuarta: | IMHO thats how it should actually be |
| [17:18:25] | stuarta: | ajax the ui! |
| [17:18:31] | stuarta: | power to the people! |
| [17:18:51] | ** stuarta suspects something is in his tea.... ** | |
| [17:19:07] | Beirdo: | don't make me throw something at you, you 99%-er, you! |
| [17:19:24] | Beirdo: | like... a job application |
| [17:19:26] | ** stuarta blows a raspberry! ** | |
| [17:19:35] | stuarta: | :) |
| [17:19:40] | Beirdo: | :) |
| [17:19:53] | stuartm: | well as it happens mythui has long included seperate Load() and Init() methods of MythScreenType() to allow data to be loaded in the background – I might actually point out that my first mythui version of PBB did load it all in the background, but people hated the effect and it was changed |
| [17:20:06] | danielk22: | stichnot: I think we could address the problem when a lock is held. We could create MMutex,MMutexLocker which track such things. But this wouldn't help with the issue of something long blocking being added in the UI thread. |
| [17:20:12] | stuarta: | smite the non believers! |
| [17:21:09] | stichnot: | stuartm: what was the hated effect? blank buttons that filled in as you watched? |
| [17:22:18] | stuartm: | stichnot: almost, buttons appearing, we added the whole button rather than filling the list with empty buttons and then populating the information – same deal really |
| [17:23:57] | stichnot: | ok. i think my v8 lazystrings patch had that effect (before a small mythui fix), and I hated that. :) |
| [17:24:38] | stuartm: | ironically people voted for waiting a couple of seconds before displaying the screen rather than loading it immediately and populating it as information was loaded |
| [17:24:55] | stuarta: | you really can't help some people |
| [17:26:55] | stuartm: | stichnot: remember to include the ability to interrupt the thread very quickly should the user back out of the screen before it completes |
| [17:27:10] | stichnot: | I guess once you start having to wait 10 seconds, your perspective may change |
| [17:27:41] | stuarta: | possibly the best compromise is wait till you have enough to build the screen and then background the rest |
| [17:27:45] | stuarta: | ? |
| [17:28:14] | stichnot: | stuartm: yeah, my intention was to test this and other potential races by adding like a 1-second delay between processing each item |
| [17:28:20] | stuartm: | we can knock that down some by dropping some of the date strings from ToMap(), some of those can probably be achieved through templating and don't need to be hardcoded |
| [17:30:54] | stichnot: | stuarta: yes, that would be my intended effect |
| [17:31:38] | danielk22: | stichnot: With previews we use a FILO queue, so anything currently on screen gets generated first, then anything currently off-screen. |
| [17:32:12] | MythBuild: | Hey! build cppcheck-master #868 is complete: Success [build successful] |
| [17:32:12] | MythBuild: | Build details are at http://code.mythtv.org/buildbot/builders/cppc . . . r/builds/868 |
| [17:32:21] | stichnot: | stuartm: true, but I would still have the same problem once I hoard 5000 recordings on my RaspberryPi :) |
| [17:32:22] | knightr (knightr!~knightr@mythtv/developer/knightr) has joined #mythtv | |
| [17:33:05] | seeker_ (seeker_!~seeker@unaffiliated/seeker) has joined #mythtv | |
| [17:33:55] | stuartm: | 5000 would be impressive, I don't have room for the 450 recordings I've got, in fact right now I'm reluctantly deleting a lot of stuff unwatched to make room |
| [17:35:34] | seeker (seeker!~seeker@unaffiliated/seeker) has quit (Ping timeout: 245 seconds) | |
| [17:35:34] | seeker_ is now known as seeker | |
| [17:35:35] | stuartm: | when an hour long recording is 4.5–5GB it's amazing how quickly space disappears |
| [17:35:39] | knightr__ (knightr__!~knightr@69-165-170-178.dsl.teksavvy.com) has quit (Ping timeout: 260 seconds) | |
| [17:36:05] | stuartm: | and blu-ray rips running at 13–17GB per episode ... |
| [17:38:10] | stichnot: | I think jya and I are both approaching 3000 recordings in 6TB storage |
| [17:38:20] | Beirdo: | stuartm: more fun for us to chase. |
| [17:38:52] | Beirdo: | oO |
| [17:39:08] | Beirdo: | what doesn't it like about AddLogLine, and why only in statusbox.cpp? |
| [17:40:07] | Beirdo: | a better question... |
| [17:40:27] | Beirdo: | why is AddLogLine being called directly? |
| [17:40:49] | stichnot: | I have this philosophy that 1 day a week, every developer should have to use low-end hardware so that they can understand how the "other half" lives (or the "other 99%" for Beirdo...) |
| [17:41:20] | Beirdo: | hahah |
| [17:41:22] | Beirdo: | no thanks |
| [17:41:34] | Beirdo: | we put the hardware requirements higher for a reason |
| [17:41:49] | Beirdo: | ooooh |
| [17:42:07] | Beirdo: | AddLogLine is not the logging I was thinking of. |
| [17:42:21] | Beirdo: | never mind then. |
| [17:42:59] | Beirdo: | stichnot: I do have an Atom box that will get a new build eventually |
| [17:43:19] | Beirdo: | just had too many things to work on to bother |
| [17:44:20] | Beirdo: | it will also need VAAPI (old GMA500 box) |
| [17:44:31] | stichnot: | all 3 of my frontends are ION, and delays drive me crazy, so I tend to stay on top of these things |
| [17:45:55] | Beirdo: | hehe |
| [17:47:18] | stichnot: | my biggest annoyance at the moment is using the cutlist editor on HD-PVR h.264 recordings. The hdpvr puts keyframes only every 128 frames, and the ION decodes in about 2x realtime speed, so moving forward and backward is quite painful |
| [17:48:44] | Beirdo: | aye. Wrong processor for the job |
| [17:50:43] | stichnot: | #9727 was an attempt to improve that, but only has limited effectiveness. I'm thinking of just giving up and building a beefy frontend for editing |
| [17:50:56] | stichnot: | also I want to write a proper web-based editor |
| [17:52:44] | Beirdo: | if ((b1 < 0x0f) && (b1 > 0x0f)) |
| [17:52:54] | Beirdo: | ummm, that aint' gonna do squat |
| [17:53:09] | Beirdo: | line 61 on the cppcheck report |
| [17:54:03] | Beirdo: | lines 68 and 69 are bullshit |
| [17:54:15] | Beirdo: | Redundant condition: If diff < 0, the comparison diff < -900000 is always true. |
| [17:54:20] | Beirdo: | ummm, so not true |
| [17:54:27] | Beirdo: | how about diff = -1 |
| [17:54:48] | Beirdo: | that's a cppcheck bug |
| [17:55:24] | stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has quit (Ping timeout: 255 seconds) | |
| [17:55:40] | Beirdo: | if the terms were the other way around, it would be valid |
| [17:56:13] | stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has joined #mythtv | |
| [17:56:34] | Beirdo: | and line 69 could be made more obvious with () |
| [17:57:50] | zombor_ (zombor_!~zombor_@kohana/developer/zombor) has quit (Read error: Connection reset by peer) | |
| [17:58:10] | zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [18:00:56] | stuartm: | the statusbox stuff is easy to fix, but I'm not sure why it considers it to be an error and not a warning |
| [18:01:01] | stichnot: | line 68 seems valid but just misreported by cppcheck |
| [18:01:37] | stuartm: | personally I'd rm -rf statusbox.* – it's an anachronism and hideous |
| [18:01:54] | stichnot: | line 69 seems like cppcheck doesn't know operator precedence order |
| [18:02:41] | stuartm: | http://sourceforge.net/apps/trac/cppcheck/ << File bug reports here |
| [18:05:13] | stuartm: | in fact, all the statusbox stuff is really a false positive, the check which is failing is a leak check but that code isn't leaking |
| [18:06:27] | stuartm: | we are running an unstable version of cppcheck, so a number false positives are perhaps expected |
| [18:18:40] | seeker (seeker!~seeker@unaffiliated/seeker) has quit (Remote host closed the connection) | |
| [18:18:41] | seeker (seeker!~seeker@unaffiliated/seeker) has joined #mythtv | |
| [18:22:50] | stichnot: | so cppcheck line 61 led me to the wikipedia XDS page http://en.wikipedia.org/wiki/Extended_Data_Services which says that ABC and CBS use this mechanism to send private information to their affiliate. I wonder if this is related to the "AFD: VBI: Unknown descriptor: 153" logs I mentioned earlier |
| [18:25:53] | seeker (seeker!~seeker@unaffiliated/seeker) has quit (Quit: Colloquy for iPhone - http://colloquy.mobi) | |
| [18:27:04] | sphery: | stuartm: based on what I saw when I went in to remove the frontend status box log viewer, +1 on the rm -rf statusbox.* |
| [18:29:10] | sphery: | it seems it was designed for one thing (log viewing), then other things were added after by re-using/abusing the log viewer stuff and that it would be better if redesigned for current uses |
| [18:30:46] | stuartm: | yep, I'm not sure we need a log viewer in the frontend, an 'event' timeline maybe |
| [18:31:28] | stuartm: | we probably don't need the machine status info, at the least it could be made optional and condensed down to what's important |
| [18:31:45] | sphery: | yeah, really the log viewer seemed necessary under the old model of "keep log messages in DB until they're OK'ed by the user" |
| [18:32:28] | sphery: | we've now removed that model (since no one in their right mind would go through all the messages--especially now that all the messages are in there rather than just a few random ones that were logged separately to the DB) |
| [18:32:57] | stuartm: | there are maybe three or four things a user needs to know – when was something recorded, when was it expired or delete and maybe when a job was run on it |
| [18:33:18] | stuartm: | we don't need reschedule info and that sort of thing |
| [18:34:11] | stuartm: | mythfilldatabase run could also appear in the 'event' timeline removing the need for a separate listings data view |
| [18:34:37] | sphery: | and the browser-based UI is probably much better for log viewer, anyway. I had actually considered just having a "frontend log viewer" that pops up the services api/backend html log viewer page in MythBrowser (but doing so will require some changes to the UI to make it more remote friendly--not to mention actually doing a usable UI, which it's lacking, now, because of constraints imposed by jquery and my inability to figure out a way to work ... |
| [18:34:43] | sphery: | ... around them) |
| [18:35:26] | stuartm: | tuner status is redundant, you can get that same info from the upcoming recordings screen, same for the schedule status |
| [18:36:27] | sphery: | yeah, I think that screen definitely needs to be re-thought--and possibly "optimized" out/consolidated with other information in other places |
| [18:36:32] | gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has joined #mythtv | |
| [18:36:43] | stuartm: | probably value in the auto-expire listing, but that gets us down to two views/screens instead of the half dozen we've got now |
| [18:37:27] | stuartm: | then again, the auto-expire listing could be merged with the 'delete recordings' screen that some themes offer |
| [18:37:36] | sphery: | IMHO, auto-expire listings should be just another view in Watch Recordings (or the annoying-that-we-still-have-it Delete Recordings) |
| [18:38:51] | sphery: | it only really shows things in a different order and lets you delete them or change auto-expire status, right. Watch Recordings shows you all available information and even lets you play it, first, to make sure |
| [18:39:10] | sphery: | so would just be adding a new sort order in Watch Recordings |
| [18:39:17] | stuartm: | so in a couple of minutes we've already figured out that rm -rf statusbox.* actually is the right course of action ;) |
| [18:39:28] | sphery: | hehe, agreed :) |
| [18:40:02] | stuartm: | shall we put that on the list of things to target for 0.26? |
| [18:40:31] | sphery: | sounds good to me |
| [19:02:10] | Goga777 (Goga777!~Goga777@128-71-48-98.broadband.corbina.ru) has joined #mythtv | |
| [19:20:58] | danielk22: | sphery: The Delete Recordings screen in MythCenter-wide the same as Watch Recordings except for the ordering and the size of each recording is shown. I don't think adding that mode to the Watch Recordings screen makes a lot of sense from a UI perspective. But having to theme it separately is a pain. |
| [19:23:17] | danielk22: | Watch Recordings is already a pretty complex screen and some themes don't even tell you which recording group you are viewing so you can easily get lost. Adding a 'delete' mode to it would just add confusion. |
| [19:28:00] | Goga777 (Goga777!~Goga777@128-71-48-98.broadband.corbina.ru) has quit (Remote host closed the connection) | |
| [19:28:12] | zombor_ (zombor_!~zombor_@kohana/developer/zombor) has joined #mythtv | |
| [19:29:30] | Goga777 (Goga777!~Goga777@128-71-48-98.broadband.corbina.ru) has joined #mythtv | |
| [19:31:38] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Ping timeout: 252 seconds) | |
| [19:36:18] | sphery: | danielk22: I'm saying I have no idea why we even have a separate delete screen... My "new mode" for Watch Recordings was to replace the Auto-expire list in the frontend status box. |
| [19:38:13] | sphery: | FWIW, I just don't see any reason why a delete screen (or mode or view or ...) is necessary at all. If there are problems with information display in Watch Recordings, we should fix those rather than use a "different screen to work around the problems with Watch Recordings" approach. |
| [19:38:37] | danielk22: | sphery: I'm saying adding more functionality to "Watch Recordings" is not unequivocally a good thing. It adds complexity and makes it harder for users to start using MythTV. |
| [19:38:44] | sphery: | and, I think the "some themes don't even tell you which recording group you are viewing" is more a problem with our stupid settings for Watch Recordings |
| [19:40:58] | sphery: | about the auto-expire list, all the functionality provided by that list is available in watch recordings (see autoexpirable recordings, see deleted recordings, delete recordings, change autoexpire status...). the only thing the autoexpire list does is provide a list in priority order (and not even the order that things /will/ be expired) |
| [19:43:00] | sphery: | the specific "stupid setting" that prevents seeing which recording group you're viewing (or causes themes to be designed so they don't show group?) is: DispRecGroupAsAllProg = 'Show filter name instead of "All Programs": If enabled, use the name of the display filter currently applied in place of the term "All Programs" in the playback screen.' (default value is false) |
| [19:43:08] | zombor_ is now known as zombor | |
| [19:45:32] | sphery: | and as far as allowing users to use a Watch-Recordings-like view for autoexpire management causing it to be harder to use mythtv, I don't care if there's a separate menu entry in the main menus or whatever that goes in and shows it... I just think that a cut-down list of program titles/subtitles without ability to play back and do other management is useless and annoying... |
| [19:45:51] | sphery: | a recording should be a recording wherever I'm at, and I should be able to play it, change recgroup, change autoexpire, ... |
| [19:54:45] | stuartm: | my argument for dropping the statusbox stuff would be that we don't need a dozen different places to view the same information, it's confusing for the user and harder on the themer |
| [20:01:43] | stuartm: | statusbox itself is a mess, and I don't believe the user needs access to all the information contained there from the comfort of the couch. a simpler timeline of key events is really all that most people would want so they can answer simple questions such as "where did that recording go?" – Answer "Recording 'ABC' deleted by {user} on Wed 14th, 21:23" |
| [20:16:27] | stichnot: | stuartm: I was noticing that PlaybackBox::updateRecList() makes many calls to MythUIButtonListItem::DisplayState() for each item. Each of those calls is likely to call MythUIButtonList::Update() which calls MythUIType::SetRedraw(void). Am I right in thinking there are performance opportunities here? |
| [20:17:46] | stichnot: | for example, most of the items are not even visible, in which case it doesn't seem necessary to do UI computations. |
| [20:18:19] | stuartm: | not much of one, we only redraw once maybe twice if the timing is bad, SetRedraw() doesn't do any drawing, it simply marks it as needing a redraw at the next opportunity |
| [20:19:38] | stichnot: | doesn't SetRedraw do a lot of calculations of what regions need redrawing? |
| [20:20:27] | stuartm: | nothing with any appreciable overhead |
| [20:21:10] | stuartm: | it just determines the area in need of redrawing, which is simple addition |
| [20:21:36] | stichnot: | I recall that to meet danielk22's 50ms time requirement in #10161, I had to make the m_states calculations in updateRecList lazy as well |
| [20:21:55] | stuartm: | that said, PBB could use DisplayStates instead of calling DisplayState for each state, marginally less work |
| [20:22:45] | stuartm: | stichnot: that's because actually determining the states is computationally expensive, not the UI side of it |
| [20:23:15] | danielk22: | sphery: To me the autoexpire list seems like something only autoexpire developers could love. Couldn't we just drop it altogether? |
| [20:23:16] | stuartm: | some of the states mean querying information from elsewhere |
| [20:24:17] | stichnot: | I don't see anything particularly expensive in updateRecList |
| [20:24:26] | danielk22: | sphery: I didn't know about that setting.. I think we should just make that the default for the next release and drop the setting. |
| [20:24:31] | stichnot: | seems to be all simple accessors |
| [20:24:37] | stuartm: | danielk22: that works for me, the 'watchlist' provides the sort of functionality a user might conceivably want if it's a question of watching recordings before they expire |
| [20:24:40] | stichnot: | but there are a lot of them |
| [20:26:01] | stuartm: | users don't need to see behind the curtain |
| [20:27:03] | stuartm: | stichnot: try using DisplayStates() instead, I'd be very surprised if it makes a significant difference but you never know ... |
| [20:27:57] | stichnot: | stuartm: I don't see any DisplayStates(). do you mean SetStatesFromMap() ? |
| [20:28:02] | danielk22: | stichnot: Simple accessors compile away in C++, but the extract_* functions can be expensive. |
| [20:29:07] | stuartm: | stichnot: yes, sorry, confusing the name |
| [20:30:55] | sphery: | danielk22: some users use the autoexpire list to manually delete old shows and/or identify shows that are about to be expired that they've decided to keep (and want to change to disallow expiration), but I don't think it will be missed that much (at least not if removed from mythfrontend, especially when we have mythbackend --printexpire and possibly other approaches to getting the list (services API?)) |
| [20:30:59] | danielk22: | stichnot: For instance, extract_commflag_state does a DB query. |
| [20:31:15] | sphery: | and I would love to remove DispRecGroupAsAllProg |
| [20:31:46] | stichnot: | I see. Though I don't think any of those are in updateRecList, probably quite deliberately |
| [20:34:12] | stichnot: | anyway, it looks like this was a dead end anyway. I thought I could reuse one of the InfoMap encapsulating event types in mythevent.h, for some reason thinking m_strings was an InfoMap type |
| [20:36:24] | stichnot: | I think I will just have to create a new event type that wraps QMap<QString, TextProperties> m_strings and InfoMap m_states, and use void SetTextFromMap(QMap<QString, TextProperties> &stringMap) and void SetStatesFromMap(const InfoMap &stateMap) |
| [20:37:28] | zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection) | |
| [20:46:41] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit () | |
| [20:49:02] | Goga777 (Goga777!~Goga777@128-71-48-98.broadband.corbina.ru) has quit (Read error: Connection reset by peer) | |
| [20:57:28] | stuarta: | stichnot: my current prod frontend is a lowly celeron which also has the benefit of XvMC :) |
| [21:00:24] | stichnot: | sweet! so you also get to feel all the pain |
| [21:02:55] | skrock (skrock!~martin@c-167270d5.024-74-736b7610.cust.bredbandsbolaget.se) has joined #mythtv | |
| [21:09:44] | stuarta: | aye, it's struggling on some simple content atm, however, the cpu isn't pegged, so it's an interesting research project to find out why |
| [21:10:24] | stuarta: | if i can work out how to use the frontend telnet interface to start recording playback, i can do all sorts of nice profiling |
| [21:10:54] | javatexan (javatexan!~Adium@129.62.151.124) has quit (Ping timeout: 260 seconds) | |
| [21:11:21] | stuartm: | heh, but he won't be able to upgrade 0.25/0.26 and see the benefits, since XvMC has been removed ;) |
| [21:11:57] | stuarta: | i can upgrade, i just lose the very little XvMC gave me. |
| [21:12:17] | stuarta: | iirc. i've been running without it for a while since it crashed the xserver on one ubuntu release |
| [21:14:39] | stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has quit (Quit: ChatZilla 0.9.88.1 [Firefox 10.0.2/20120215223356]) | |
| [21:16:12] | stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has joined #mythtv | |
| [21:19:50] | stuartm: | it's all about vdpau these days anyhow |
| [21:27:13] | kenni: | knightr: I've just updated the themestrings, did you have further changes or are we good for 0.25? |
| [21:30:43] | stuartm: | kenni, knightr: are you using -no-obsolete when updating the ts files? I'm concerned that some translators are wasting their time translating the 270+ obsolete strings |
| [21:31:34] | stuartm: | maybe there's no good time to do it because of the conflicts it might cause |
| [21:32:50] | kenni: | stuartm: In general we never update the ts files, due to potential conflicts. We have a section on the wiki explaining why and when the translator should and shouldn't use --no-obsolete |
| [21:35:19] | kenni: | stuartm: You can see the yellow note at www.mythtv.org/wiki/Translation#Keeping_your_translation_up-to-date |
| [21:37:37] | j-rod is now known as j-rod|afk | |
| [21:37:52] | justinh (justinh!~justin@cpc10-salf5-2-0-cust50.10-2.cable.virginmedia.com) has quit (Quit: BYE) | |
| [21:38:17] | kenni: | stuartm: Argh, sorry, that should have been http://www.mythtv.org/wiki/Translation#Update_translation_files |
| [21:42:36] | skrock (skrock!~martin@c-167270d5.024-74-736b7610.cust.bredbandsbolaget.se) has quit (Quit: WeeChat 0.3.7) | |
| [21:53:52] | kenni: | also, when the translators update their translation files without --no-obsolete (like we tell them to do on the wiki), all obsolete strings will still get marked as obsolete and hence be untranslatable in linguist. Eg. they should never be able to translate any obsolete strings, as long as they update their translation files (with or without --no-obsolete). |
| [21:54:48] | stuartm: | hmm, that must be a new feature of linguist, I'd swear that it used to permit translation of obsolete strings in the past |
| [21:58:56] | stuartm: | translation stats show an both an 'es' and an 'es_es' translation? |
| [21:58:57] | Cougar (Cougar!~cougar@kkk.version6.net) has quit (Quit: Cougar) | |
| [22:01:13] | kenni: | ok, I don't remember seeing that behaviour before, so I suppose it must be a couple of years back :) The obsolete strings have been grayed out for as long as I can remember, the purpose of --no-obsolete should just be to remove these untranslatable strings and make the file smaller |
| [22:01:45] | stuartm: | kenni: it might have been under QT3 |
| [22:01:53] | kenni: | Spanish/international and Spanish/Spain |
| [22:02:24] | kenni: | probably, I don't remember when I switched to QT4 :) |
| [22:03:34] | stuartm: | kenni: there's an international version of Spanish which is different to the Spanish in Spain? |
| [22:04:11] | stuartm: | I've not heard of that before |
| [22:04:53] | kenni: | stuartm: apparently, I have no knowledge of Spanish whatsoever, I didn't have anything to do with it for the same reason :) |
| [22:06:39] | stuartm: | I can understand a country having their own variation on a language, e.g. es_ar but not an international collection of countries ... unless they never evolved the language in the post-colonial world while the Spanish spoken in Spain has radically evolved |
| [22:07:02] | stuartm: | it's usually the other way around |
| [22:09:16] | stuartm: | I guess in the case of South America you've got several Spanish speaking nations gathered together on a single continent, they are likely to share new words hence the evolution of an 'international' Spanish which differs from that of it's originating country |
| [22:09:57] | Beirdo: | just like US English differs from UK English |
| [22:10:00] | javatexan (javatexan!~Adium@24-155-44-62.dyn.grandenetworks.net) has joined #mythtv | |
| [22:10:09] | Beirdo: | and Quebec French from France French |
| [22:10:39] | Beirdo: | both dialects end up evolving in different directions |
| [22:10:55] | stuartm: | right, but there it's the other way around if you understand my meaning ;) |
| [22:11:19] | Beirdo: | even within Latin America, Spanish has evolved differently in different areas |
| [22:11:39] | Beirdo: | Puerto Rico and Mexico speak different dialects, for instance |
| [22:12:09] | stuartm: | Beirdo: well that's what I'd expect to happen, hence maybe there isn't an 'international' version of Spanish at all |
| [22:12:12] | Beirdo: | much of it seemed to me to be the adoption of the Pre-Spanish native languages |
| [22:12:43] | Beirdo: | yeah, it would be hard to pick ONE that could be called that :) |
| [22:13:12] | Beirdo: | if you did, it likely would end up being Mexican Spanish due to population |
| [22:13:40] | stuartm: | which then begs the question, just what is our 'es' translation if it's not Spanish Spanish and it's not 'international Spanish' |
| [22:13:59] | Beirdo: | a mutt, likely |
| [22:14:09] | Beirdo: | we had one translator in Chile, one in Spain |
| [22:14:16] | Beirdo: | they kept correcting each other |
| [22:14:26] | Beirdo: | why we couldn't split it, I dunno |
| [22:14:52] | stuartm: | should it more correctly be labelled es_pr, or es_cl, or ... |
| [22:14:54] | javatexan (javatexan!~Adium@24-155-44-62.dyn.grandenetworks.net) has left #mythtv () | |
| [22:15:36] | stuartm: | Beirdo: we that seems to be what did happen, there is now an es_es translation (spanish spanish), and an 'es' translation (unknown spanish) |
| [22:15:36] | Beirdo: | yeah, I would guess that the one from Chile should be marked as such, and the one from Spain as es_ES |
| [22:15:38] | sphery: | isn't it usually that you use a "generic" language translation if a regional variant isn't available, so perhaps "es" isn't "an agreed upon Spanish variant for a group of countries" so much as "a good starting point for a Spanish-speaking country for which we don't yet have a regional translation" |
| [22:15:51] | Beirdo: | oh |
| [22:16:19] | kenni: | I don't know the answer, perhaps knightr can give a better explanation for the reasoning behind it. I'm also off to bed now :) |
| [22:16:22] | Beirdo: | should make it es_CL, I bet |
| [22:16:57] | ** stuarta hangs mythtv-setup ** | |
| [22:17:00] | Beirdo: | if only I could get my ex-brother-in-Law to ditch his Dish PVR and use MythTV, I bet we could get an es_PR from him :) |
| [22:17:32] | stuartm: | sphery: I guess that depends if the translation in question is generic or if it has a heavy Chilean influence |
| [22:17:40] | Beirdo: | wonder if we have any es_CU users? |
| [22:17:50] | stuartm: | Beirdo: heh, suspect not |
| [22:18:04] | sphery: | after all, users without a clue complain "I don't live in New York City, so why should I have to choose America/New_York as my time zone identifier", so I wouldn't be surprised to hear users from a Spanish-speaking country for which we don't offer a country-specific translation complaining that they shouldn't have to choose Spanish/Spain because they don't live in Spain. |
| [22:18:07] | Beirdo: | yeah, likely not, their general economy sucketh |
| [22:18:11] | stuartm: | although the way things are evolving there ... |
| [22:19:26] | Beirdo: | sphery: well, then they can provide it |
| [22:19:29] | stuartm: | Beirdo: getting computers into Cuba is hard enough, internet access is harder still and special hardware like TV tuners? (At least the world affairs report I saw a few months ago was saying as much) |
| [22:19:38] | sphery: | but I agree that if it is actually a Chilean translation, it should be fixed... I just always assumed it was generic. |
| [22:19:54] | Beirdo: | there's no such thing as a generic language |
| [22:20:10] | Beirdo: | even US vs UK vs CA has differences for English |
| [22:20:21] | Beirdo: | doesn't mean we can't understand each other |
| [22:20:22] | sphery: | generic meaning "a translation without significant use of regional variants" |
| [22:20:43] | Beirdo: | if there was a way of saying es_LatinAmerica... |
| [22:20:44] | stuartm: | ̣¿que? |
| [22:20:47] | Beirdo: | maybe |
| [22:22:58] | Beirdo: | anyways, there is definitely a marked difference between Latin America Spanish (which are not all one dialect, but reasonably similar) and mainland Spain |
| [22:23:07] | Beirdo: | pronunciation included |
| [22:23:35] | Beirdo: | even my gringo ears could tell the difference |
| [22:23:42] | stuartm: | sphery: well that gets tricky when dealing with new technology, if the languages tend to diverge when colonial rule ends then any new technology which needs naming will often end up with different words – so if television could be known by one word in Latin America and another in Spain |
| [22:24:05] | Beirdo: | yup |
| [22:24:36] | stuarta: | dammit. deadlocked it again |
| [22:25:29] | Beirdo: | http://upload.wikimedia.org/wikipedia/commons . . . Americas.PNG |
| [22:25:53] | Beirdo: | that also gives some insight as to why the language dialects are so varied |
| [22:26:08] | stuartm: | the nature of MythTV means that lots of strings require the use of such words, it already causes lots of problems for translators because their language has no official word for many things we've named in English |
| [22:26:28] | Beirdo: | especially when you remember that "Native American" means many many many different tribes |
| [22:27:28] | stuartm: | the French in particular struggle because they so hate the English that they really hate to incorporate Anglicised words into their language – which is a problem when most of the worlds new technology is developed and first named in English speaking nations |
| [22:28:06] | Beirdo: | wow, so they are claiming 3/4 of PR is caucasian? I think they have odd definitions then |
| [22:28:13] | Beirdo: | I'd put it at 2/3 mulatto |
| [22:29:18] | ** Beirdo shrugs ** | |
| [22:30:03] | Beirdo: | anyways, yeah, makes things rather odd to translate cleanly, and I think stuartm has hit the main reason :) |
| [22:30:48] | knightr_ (knightr_!~knightr@69-165-170-178.dsl.teksavvy.com) has joined #mythtv | |
| [22:31:50] | sphery: | Yeah, in theory a generic translation would attempt to use words that are most likely to be understood by people in both areas... like you'd say "elevator" instead of "lift", primarily because it's more likely that those in GB have been exposed to that term due to considerable exposure to American pop culture and literature than that those in US would know what lift is supposed to mean. You'd say, "American football" (something we in US ... |
| [22:31:56] | sphery: | ... wouldn't consider doing, normally) so it's clear to those in both US and GB. In other words, you choose the least-likely-to-confuse phrasing for whatever you're trying to say. Granted, that's actually harder than getting someone to do specific translations, but if someone is willing and able, it's a good thing for those who aren't in one of the countries with an active translator working on the project. |
| [22:33:17] | stuartm: | I still struggle to understand what you guys mean by 'color' |
| [22:33:30] | Beirdo: | well (in my experience), PR, Venezuela, Colombia, Dominican Republic... kinda are "interchangable" language-wise |
| [22:33:52] | Beirdo: | and Mexico/Guatemala/Nicaragua/etc |
| [22:34:08] | knightr (knightr!~knightr@mythtv/developer/knightr) has quit (Ping timeout: 252 seconds) | |
| [22:34:15] | Beirdo: | not 100% sure further south in South America |
| [22:34:43] | Beirdo: | anyways :) |
| [22:35:22] | Beirdo: | yeah well, makes it hard for stuartm to be a good neighbor. He's too busy being a good neighbour. |
| [22:43:15] | knightr_: | stuartm, if they use Qt Linguist they can't translate the obsolete entries unless they haven't run lupdate as we instructed them... |
| [22:43:44] | knightr_: | ok, I see Kenni mentionned it... |
| [22:44:14] | knightr_: | (dion't worry Stuart, we had this covered...) |
| [22:44:17] | gigem: | sphery, stuartm: i (probably not surprisingly) like the tuner and schedule status information and would be upset to see them ripped out without a acceptable replacement. that being said, an acceptable replacement could be a hopefully-easy-to-theme, popup, html screen (like progdetails) acceessible from viewscheduled. |
| [22:44:43] | knightr_: | es is supposed to be international, es_es is the Spanish/Spain one... |
| [22:45:15] | knightr_: | (oops, once again Kenni said it..) |
| [22:45:30] | stuartm: | knightr_: maybe easier to read backwards ;) |
| [22:47:36] | knightr_: | Beirdo, Quebec French has a tendency to use more French word than France French but we tend to borrow more expressions from English than our French "cousins"... |
| [22:48:29] | Beirdo: | knightr_: ummm, yeah. Quebec stopped evolving the language hundreds of years ago :) |
| [22:48:36] | stuartm: | gigem: I think danielk22 might have put his finger on it when he said "To me the autoexpire list seems like something only autoexpire developers could love." – There are screens in mythfrontend which only seem to exist because developers working on a particular bit of code want a way to access information useful for debugging without resorting to the command line |
| [22:48:54] | knightr_: | We're looking for translators for the Es one but if we don't find any, we could get rid of it, the Es_es one is a better starting point now I think... |
| [22:49:02] | Beirdo: | or at least evolving it the same way as France :) |
| [22:50:48] | knightr_: | Beirdo, for the French translation the French guys abolutely want to translate tuner by tuner... |
| [22:51:08] | stuartm: | IMHO if we have to provide those screens they should be optional so that they can be omitted entirely from themes, both sparing themers the work and ordinary users the complexity |
| [22:51:17] | knightr_: | When the right word for it, here and in France, is syntoniseur |
| [22:52:35] | knightr_: | stuartm, the person who was pushing for a generic Spanish translation was Reynaldo but all the translators we have for Spanish are from Spain and want to use their variant of Spanish... |
| [22:52:59] | knightr_: | One of them explained to me that there are actually differences in the tenses they use and things like that... |
| [22:53:45] | stuartm: | knightr_: I'm surprised that the Catalan translation is lagging so far behind (almost non-existent) |
| [22:54:02] | gigem: | stuartm: that's why i said "hopefully-easy-to-theme" and my suggestion to use html. it should be simple enough theme one generic window capable of displaying any html. |
| [22:54:10] | knightr_: | We always said that we wanted to keep old translations as a starting point for new translations but in the case of Spanish and a few other languages, I'm no longer sure it's such a good idea... |
| [22:54:22] | gigem: | s/enough theme/enough to theme/ |
| [22:54:45] | knightr_: | (actually I should say as a starting point for new translators to work on...) |
| [22:55:22] | Beirdo: | knightr_: what happened to the Chile based guy? |
| [22:55:38] | knightr_: | stuartm, unfortunately we have no translator for it IIRC... |
| [22:55:57] | knightr_: | Beirdo, wasn't the Chile guy Reynado? |
| [22:56:08] | Beirdo: | ahhh, could be. |
| [22:56:25] | stuarta: | http://www.dvb.org/technology/standards/index.xml <- all the technical documents we could possibly need |
| [22:56:26] | knightr_: | s/Reynado/Reynaldo |
| [22:57:02] | Beirdo: | well, if someone gets miffed that it's the wrong type of Spanish, they are welcome to step up and do something about it |
| [22:57:05] | stuartm: | gigem: that's reasonable enough, still doesn't stop me wanting a way to omit certain things from a theme entirely, I dream of creating a complete theme including a menu theme that leaves out all the acculuated stuff that I believe most users don't need :) Just call me Steve ;) |
| [22:58:09] | knightr_: | stuartm, I'm still testing online translation tool, maybe that would bring us new translators... AFAIK, they fixed almost all the problems I reported... |
| [22:58:11] | stuartm: | stuarta: is that new? I don't recall them offering a comprehensive listing of all the standards in one place before |
| [22:58:18] | knightr_: | an online... |
| [22:58:21] | stuarta: | i've only just found it |
| [22:58:31] | Beirdo: | knightr_: cool, which one? |
| [22:59:09] | knightr_: | Beirdo, Pootle... We could even customize it somewhat I guess since it's written in Python... |
| [22:59:10] | stuartm: | s/acculuated/accumulated/ now that's what I call a typo |
| [23:00:09] | knightr_: | Beirdo, looks like these guys really want to get the Qt ts format right and they fixed the most glaring bugs the tool had with Qt ts files... |
| [23:00:50] | Beirdo: | nice |
| [23:00:52] | stuartm: | stuarta: I've pulled some of those from official sites before, but that's the first time I've seen a complete offering of the lot before |
| [23:01:18] | stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has quit (Ping timeout: 245 seconds) | |
| [23:01:18] | stuarta: | aye, it's got stuff in there i didn't even know existed! |
| [23:02:20] | knightr_: | Beirdo, I have a server setup for it in my DMZ, only problem is my old firewall is toast (it was an old Pentium I which recently died) and I'm currently using an old WRT54G which doesn't support doing a DMZ... I want to replace what I had with PfSense... |
| [23:02:36] | Beirdo: | ahhh |
| [23:03:06] | Beirdo: | /win 15 |
| [23:03:09] | Beirdo: | ergh |
| [23:08:20] | knightr_: | stuartm, with the help of my contact in the Spanish language translation team I could try to find out if there is any interest at all to maintain the generic Spanish translation (as Reynaldo put it, the International Spanish one), if there is none I could get rid of it... Anyway, the Spanish/Spain translation is most likely a better starting point now (close to 100% completed) than that translation and there doesn't seem to be any inter |
| [23:08:20] | knightr_: | est to maintain it (which I find very surprising...) |
| [23:21:50] | knightr_: | Beirdo, concerning the countries and their use of Spanish, the Spanish translator I spoke too was more or less saying the same thing you did, there's like an american and an european version of spanish, the idea was to make es the more internaitonal Spanish translation for the "american" version of Spanish (since it would be used by people of all those countries...) |
| [23:22:58] | knightr_: | (but nobody seems to be interested to maintain it, ALL the people interested to help translate in Spanish are from Spain...) |
| [23:25:53] | knightr_: | Kenni, John needed to fix something in his theme... As for string there would have been one I would have liked to fix but I would be breaking the string freeze by doing so... |
| [23:39:47] | knightr_: | s/string/strings |
| [23:40:06] | coling_ (coling_!~colin@cpc1-sgyl30-2-0-cust727.sgyl.cable.virginmedia.com) has joined #mythtv | |
| [23:40:20] | coling (coling!~colin@cpc1-sgyl30-2-0-cust727.sgyl.cable.virginmedia.com) has quit (Read error: Operation timed out) | |
| [23:44:23] | knightr_: | sphery, es is meant to be generic but if nobody is interested to maitain it we might as well eventually get rid of it and eventually es_es might be a better starting point to create a new one since it's almost a 100% complete.... |
| [23:48:49] | Beirdo: | well even within Latin America there are some big differences, but whatever works, I guess |
| [23:48:58] | knightr_: | stuartm, I sent screen caps to Piotr (Warpme's real name) so that he can see what I was talking about. As you mentionned the problem is most likely that he didn't size his windows properly... |
| [23:49:10] | Beirdo: | seems nobody Hispanic is currently bothered enough to change it |
| [23:49:52] | knightr_: | Beirdo, Reynaldo thought it was possible to have one generic enough but nobody seems to be interested to maintain it... |
| [23:50:02] | knightr_: | yep... |
| [23:50:41] | Beirdo: | so, meh :) |
| [23:51:34] | knightr_: | Beirdo, can we get a cloak on alternate account names like the one I currently have? (I'm sure I had knightr this morning but it looks like I got disconnected (happens a lot lately) and now I no longer have the cloak...) |
| [23:51:41] | knightr_: | exactly... |
| [23:52:41] | Beirdo: | if it's registered under the same master account, it should have the cloak |
| [23:52:51] | Beirdo: | likely just have to link this nick back to your main one |
| [23:53:20] | knightr_: | master account, you mean email address or something else? |
| [23:53:49] | Beirdo: | like each account with nickserv can have several nicks attached to it |
| [23:54:52] | knightr_: | ah, ok... I guess I better check how to do it... I registred it but didn't know there was a way to associate it with the other... |
| [23:55:43] | Beirdo: | in PMs to nickserv, the command is "group" I think |
| [23:56:07] | knightr_: | thank you! |
| [23:57:00] | Beirdo: | no prob :) |
| [23:58:53] | knightr_ (knightr_!~knightr@69-165-170-178.dsl.teksavvy.com) has quit (Quit: Leaving) | |
| [23:59:11] | knightr (knightr!~knightr@mythtv/developer/knightr) has joined #mythtv | |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.
