| Tuesday, October 22nd, 2013, 00:02 UTC | ||
| [00:02:25] | skd5aner: | stichnot: well, I think it would make sense for there to be some overlap, but bit rotting is probably not too desirable since people who have relied on it all of these years will be pretty upset if it's still available and only sorta works – or worse, breaks things |
| [00:03:28] | skd5aner: | I guess I ask, because if it isn't going to go away, then it needs to be continued to be maintained with any changes... if it is going to go away, then no one has to worry about maintaining it and 0.27 becomes that last release where it's supported |
| [00:04:58] | skd5aner: | I would assume a full release where the majority of the functionality is finally embedded in the backend http server, while still supporting a working mythweb for one overlapping release, probably would make sense – it ensure that the new stuff works as well (or better) than the old |
| [00:05:11] | skd5aner: | anything beyond that is definitely double work |
| [00:11:23] | tonsofpcs: | is there a new web if? |
| [00:11:56] | wagnerrp: | nothing that hasn't been around for a couple years |
| [00:12:13] | ** tonsofpcs is still on 0.25... don't tell anyone ;) ** | |
| [00:52:51] | rsiebert_ (rsiebert_!~quassel@g225061039.adsl.alicedsl.de) has joined #mythtv | |
| [00:56:00] | rsiebert (rsiebert!~quassel@g229053174.adsl.alicedsl.de) has quit (Ping timeout: 256 seconds) | |
| [01:20:44] | clever (clever!~clever@nwcsnbsc00w-142167177167.dhcp-dynamic.FibreOp.nb.bellaliant.net) has joined #mythtv | |
| [01:33:39] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 272 seconds) | |
| [01:54:53] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [02:07:19] | Guest85778 (Guest85778!~neon@109.65.184.99) has quit (Read error: Connection reset by peer) | |
| [02:07:29] | neon__ (neon__!~neon@109.67.167.207) has joined #mythtv | |
| [02:07:39] | neon__ is now known as Guest94451 | |
| [02:09:51] | _nyloc_ (_nyloc_!~quassel@p3EE2D502.dip0.t-ipconnect.de) has joined #mythtv | |
| [02:10:21] | guest42143 (guest42143!~neon@bzq-79-182-160-200.red.bezeqint.net) has joined #mythtv | |
| [02:12:42] | Guest94451 (Guest94451!~neon@109.67.167.207) has quit (Ping timeout: 268 seconds) | |
| [02:13:47] | nyloc (nyloc!~quassel@p3EE2CC6B.dip0.t-ipconnect.de) has quit (Ping timeout: 248 seconds) | |
| [02:16:43] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 272 seconds) | |
| [02:31:55] | jarle (jarle!~jarle@70.84-234-133.customer.lyse.net) has quit (Ping timeout: 272 seconds) | |
| [02:32:18] | jarle (jarle!~jarle@70.84-234-133.customer.lyse.net) has joined #mythtv | |
| [02:34:03] | peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Ping timeout: 248 seconds) | |
| [02:34:50] | peper03 (peper03!~peper03@mythtv/developer/peper03) has joined #mythtv | |
| [02:41:13] | guest42143 (guest42143!~neon@bzq-79-182-160-200.red.bezeqint.net) has quit (Ping timeout: 246 seconds) | |
| [02:45:53] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!) | |
| [02:54:56] | guest42143 (guest42143!~neon@109.67.200.214) has joined #mythtv | |
| [03:08:31] | stichnot (stichnot!~stichnot@adsl-68-127-209-56.dsl.pltn13.pacbell.net) has joined #mythtv | |
| [03:08:31] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [03:08:31] | stichnot (stichnot!~stichnot@adsl-68-127-209-56.dsl.pltn13.pacbell.net) has quit (Changing host) | |
| [03:21:05] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!) | |
| [03:30:56] | stichnot (stichnot!~stichnot@adsl-68-127-209-56.dsl.pltn13.pacbell.net) has joined #mythtv | |
| [03:30:58] | stichnot (stichnot!~stichnot@adsl-68-127-209-56.dsl.pltn13.pacbell.net) has quit (Changing host) | |
| [03:30:58] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [03:43:40] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 264 seconds) | |
| [03:44:47] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [05:17:13] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 272 seconds) | |
| [06:03:51] | SteveGoodey (SteveGoodey!~steve@host86-134-193-50.range86-134.btcentralplus.com) has joined #mythtv | |
| [06:04:45] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [06:10:13] | SteveGoodey (SteveGoodey!~steve@host86-134-193-50.range86-134.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [06:18:30] | FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has joined #mythtv | |
| [06:40:49] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 272 seconds) | |
| [07:32:28] | dgeary2 (dgeary2!~debian@pa49-187-95-34.pa.nsw.optusnet.com.au) has joined #mythtv | |
| [07:36:06] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [08:39:46] | dgeary2_ (dgeary2_!~debian@pa49-187-95-172.pa.nsw.optusnet.com.au) has joined #mythtv | |
| [08:42:33] | dgeary2 (dgeary2!~debian@pa49-187-95-34.pa.nsw.optusnet.com.au) has quit (Ping timeout: 252 seconds) | |
| [10:15:29] | stuarta: | stichnot: fyi, the mini mac remote has only 5/6 buttons |
| [11:01:01] | dgeary2_ is now known as dgeary2 | |
| [11:30:01] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv | |
| [11:34:53] | dgeary2 (dgeary2!~debian@pa49-187-95-172.pa.nsw.optusnet.com.au) has quit (Quit: Ex-Chat) | |
| [12:42:39] | Jordack (Jordack!~Jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv | |
| [13:24:52] | gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has quit (Quit: Leaving) | |
| [13:56:53] | danielk22 (danielk22!~danielk@exchange.wgen.net) has joined #mythtv | |
| [13:56:57] | dekarl-work (dekarl-work!51c8c614@gateway/web/freenode/ip.81.200.198.20) has joined #mythtv | |
| [13:58:52] | dekarl-work: | stuarta, re mini mac remote, see http://ars.userfriendly.org/cartoons/?id=19980713 on a more serious note, maybe limited remotes will simply allow only limited functionality (like enough for basic recording/video playback and thats it) |
| [14:03:48] | stuarta: | a few versions back, i could use the mini remote for everything on the frontend and it worked fine |
| [14:03:58] | stuarta: | i've not used it in that way for a long time |
| [14:04:06] | stuarta: | it's now a buildbot :) |
| [14:25:00] | gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has joined #mythtv | |
| [14:32:35] | gregL_ (gregL_!~greg@cpe-74-76-105-205.nycap.res.rr.com) has joined #mythtv | |
| [14:46:35] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 272 seconds) | |
| [14:55:01] | _charly_ (_charly_!kroseneg@sunrise.schmidham.net) has quit (Ping timeout: 245 seconds) | |
| [15:02:36] | FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has quit (Ping timeout: 252 seconds) | |
| [15:03:33] | FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has joined #mythtv | |
| [15:31:17] | stuartm: | I've never really thought a 5 button remote was a good idea, yes it might technically be possible to do everything with one, but do it as easily and as quickly? |
| [15:32:10] | stuartm: | of course the apple remote may have had 5 buttons, but I believe each one was in fact dual-action, short press vs long press, so already it's actually a 10 button remote |
| [15:33:25] | stuarta: | yes that was part of the trick |
| [15:33:34] | stuartm: | the point is that we should avoid control proliferation, it doesn't have to be limited to 5 but it needs to be less than 50 :) |
| [15:33:56] | stuarta: | iirc it has 4 arrows, ok and menu. menu being dual action |
| [15:34:08] | stuarta: | can't remember about the others |
| [15:34:36] | stuartm: | if you can't quickly and easily _all_ functions from a standard DVR remote then we're doing something wrong |
| [15:35:53] | stuartm: | I still rate the original MCE remote (with colour buttons) as the best remote design – it had everything you'd want or need for MythTV, nothing more and nothing less |
| [15:35:53] | stuarta: | and the MCE remotes are the closest thing to a "standard" we have |
| [15:37:13] | toeb (toeb!~toeb@HSI-KBW-149-172-82-128.hsi13.kabel-badenwuerttemberg.de) has joined #mythtv | |
| [15:40:04] | stichnot (stichnot!~stichnot@207.198.105.23) has joined #mythtv | |
| [15:40:04] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [15:40:04] | stichnot (stichnot!~stichnot@207.198.105.23) has quit (Changing host) | |
| [15:45:17] | stuartm: | sphery: that warning does need changing to account only for those sources with a grabber configured |
| [15:45:37] | stuartm: | although the start and end times being identical also appears wrong |
| [15:47:00] | FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has quit (Quit: FabriceMG) | |
| [15:49:57] | stichnot: | stuarta, stuartm: I think you could go pretty far with Up/Down for navigation (using a vertical theme), right for select, left for escape, and the 5th button for menu. It wouldn't be fun, but maybe functional. |
| [15:51:32] | stichnot: | I have one of these "magic wand" remotes, but still need to get it properly configured – http://www.thewandcompany.com/ |
| [15:52:02] | dekarl-work: | stuartm: iirc something funny also happens if you disconnect the video source from all inputs and then run mythfilldatabase with a grabber :) |
| [15:52:10] | stuartm: | for navigating the UI yeah that's all you'd need, I rarely use more than that myself when navigating through mythfrontend, but it would be too restricting when watching video and livetv especially |
| [15:53:03] | stichnot: | The playback OSD menu is fairly comprehensive, and now customizable so you can get to your common actions more quickly (though of course not ideally) |
| [15:54:11] | stichnot: | but on the whole I agree — barely functional and certainly not fun |
| [15:54:18] | stuartm: | I mean I make regular use of pause (I'm continually being interrupted), skip and jump (to get past adverts or sections of programmes I'm not interested in) |
| [15:54:39] | stuartm: | then in livetv you've got the extra dimension of channel browsing |
| [15:55:19] | stuartm: | subtitles, and recording |
| [15:55:57] | stuartm: | you could cram some/most of that into the menu structure but it would be incredibly tedious |
| [15:57:55] | stichnot: | I don't remember about the live TV part, but the rest are already crammed in there :) |
| [15:58:40] | stuartm: | guess I scared people into silence with my commit message last night, which is good :) |
| [16:00:42] | stichnot: | Not saying I would ever want that for myself or inflict it on others, just that it's useful to consider that extreme case in the design |
| [16:01:46] | stichnot: | maybe we should hold a button-a-thon to raise awareness and money for those poor button-deprived people |
| [16:03:10] | dekarl1 (dekarl1!~dekarl@p4FE852EF.dip0.t-ipconnect.de) has joined #mythtv | |
| [16:04:43] | dekarl (dekarl!~dekarl@p4FE8590C.dip0.t-ipconnect.de) has quit (Ping timeout: 248 seconds) | |
| [16:10:55] | sphery: | stuartm: start and end times are identical when it runs fast, but IMHO, the warning does more harm than good |
| [16:11:51] | stuartm: | the warning is fine, just needs to be more accurate |
| [16:12:18] | sphery: | whether we've cried wolf too many times that people ignore that message or they just don't notice it because they seem to have data, most users with mfdb/listings source problems tend to find out only when the number of days of listings is several fewer than they expect |
| [16:12:38] | stuartm: | and I've never known any grabber to complete in under a minute (unless the user has one channel) |
| [16:12:45] | sphery: | and since there are many reasons--that aren't problems--why there would be no additional data, I think it should be just removed |
| [16:13:21] | stuartm: | sphery: I'd be fine with leaving off the last part about it indicating a failure |
| [16:13:25] | sphery: | for example, run mfdb today and it grabs new data, then run it tomorrow but before TMS has pushed new data to their servers, and it would warn |
| [16:13:31] | sphery: | though there's absolutely no problem |
| [16:14:25] | sphery: | (and that happens often--even with suggested download times--because we ignore the suggestion if it results in our going > mythfillperiod days between runs |
| [16:15:12] | sphery: | anyway, I have never once seen a user post that warning when there was actually a problem... |
| [16:15:15] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 272 seconds) | |
| [16:15:55] | sphery: | and since many users pay attention to things like that when they're trying to get things running--and, therefore, run mfdb many times in a span of a few hours, it seems it's always there causing worries |
| [16:16:24] | sphery: | it can stay, but I think it causes more confusion than benefit |
| [16:18:35] | NightMonkey (NightMonkey!~NightrMon@173-164-139-193-SFBA.hfc.comcastbusiness.net) has joined #mythtv | |
| [16:18:35] | NightMonkey (NightMonkey!~NightrMon@173-164-139-193-SFBA.hfc.comcastbusiness.net) has quit (Changing host) | |
| [16:18:35] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [16:22:19] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Client Quit) | |
| [16:22:49] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [16:33:16] | stichnot (stichnot!~stichnot@216.239.45.91) has joined #mythtv | |
| [16:33:16] | stichnot (stichnot!~stichnot@216.239.45.91) has quit (Changing host) | |
| [16:33:16] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [16:39:12] | SteveGoodey (SteveGoodey!~steve@host86-134-193-50.range86-134.btcentralplus.com) has joined #mythtv | |
| [16:41:56] | ** dblain is getting really frustrated with mysql... every time I reboot the server it corrupts tables :( ** | |
| [16:46:21] | clever: | are you shutting it down cleanly? |
| [16:46:46] | dblain: | yep |
| [16:47:17] | dblain: | Always corrupts time zone tables, and now it's causing mythconverg to fail. |
| [16:47:59] | clever: | needs a repair table query to fix it? |
| [16:48:58] | dblain: | Thanks, but tried one already. I've decided to export all schemas that are still valid and uninstall mysql... time to start over. At least I have backups. |
| [17:09:45] | stichnot: | stuartm: quick lazy question – is the internal web server provided by a running master backend, running slave backend, or running frontend? |
| [17:12:08] | dekarl-work: | stichnot: I have one on the MBE without frontend running |
| [17:13:08] | stuartm: | stichnot: master |
| [17:13:35] | stuartm: | actually, could be on the slave too, no idea |
| [17:18:23] | dekarl-work (dekarl-work!51c8c614@gateway/web/freenode/ip.81.200.198.20) has quit (Quit: funny idea to run mythtv as realtime io when the system can't keep up without) | |
| [17:18:47] | sphery: | it's in all backends |
| [17:19:29] | sphery: | but whether the web pages/services work properly on non-master backend is a whole other question (and I'd expect some will be problematic) |
| [17:20:27] | sphery: | only one I know of that definitely works properly is the http status page |
| [17:21:37] | sphery: | (though properly doesn't mean you get the same output--you get a "this remote only" status page that knows nothing of schedules or remote cards/storage) |
| [17:24:09] | dblain: | The service api (which uses the http server) works on the slaves as well. That way if a resource is located on a slave, the client will/can pull it directly from it. |
| [17:35:35] | dblain: | stuartm: just an FYI, when I browse to the new program guide page, it changes the font size of the menu on the left. (using ie11). Figured you'd want to know the css affects more than your page. |
| [17:36:12] | dblain: | it changes back when I navigate to another page. |
| [17:37:07] | stuartm: | dblain: that's very strange, the css alls uses a high specificity to avoid exactly that sort of issue ... |
| [17:38:07] | dblain: | must be something overlooked or just another ie issue |
| [17:46:07] | dblain: | is there a pastebin equ for images? |
| [18:05:50] | toeb (toeb!~toeb@HSI-KBW-149-172-82-128.hsi13.kabel-badenwuerttemberg.de) has quit (Ping timeout: 240 seconds) | |
| [18:08:37] | stuartm: | imagebin.ca |
| [18:08:42] | stuartm: | if it's still running |
| [18:09:50] | stuartm: | dblain: the menustyle.css needs some changes, it's specifying stuff applicable to all <p> elements and the body, when judging from it's name it's meant to be specific to the menu |
| [18:10:10] | stuartm: | I'll fix that shortly, but otherwise I can't see a problem with guide.css that would explain what you are seeing |
| [18:10:14] | dblain: | stuartm: This is what I'm seeing http://mythtv.blainconsulting.com/ccsissue.jpg |
| [18:11:08] | dblain: | no rush. I know it's too early to be picky about compatibility. I've already taken too much of your time for this issue |
| [18:12:07] | stuartm: | dblain: which browser is that? It's nearly identical to the debugger that has shipped with Opera for years |
| [18:12:31] | dblain: | ie11 (windows 8.1) |
| [18:12:55] | stuartm: | interesting, wonder who ripped off whom |
| [18:13:07] | dblain: | :) |
| [18:14:49] | stuartm: | dblain: ah, ok the problem is that guide.qsp is including site.css which changes the include order, meaning that menustyle.css is overruled |
| [18:15:27] | stuartm: | I was including it there so that guide.qsp works on it's own as well as when it's incorporated into index.html |
| [18:16:06] | stuartm: | can be worked around by fixing menustyle.css so that it explicitly applies only to things below #menu |
| [18:16:15] | dblain: | glad it was simple. I don't like how we include the sub pages. Feel free to change how that works! :) |
| [18:16:18] | stuartm: | which I had already decided to do |
| [18:16:43] | stuartm: | dblain: yeah I can't see the advantage of doing it the way that we do |
| [18:17:08] | stuartm: | a frame would work just as well but with fewer complications |
| [18:19:04] | dblain: | I usually don't like frames either. How about just standard set of includes for header & menu? |
| [18:20:28] | stuartm: | well I've always hated frames too, includes for header/footer/menu would be fine by me |
| [18:21:50] | dblain: | Not sure if I implemented server side includes... should be easy enough to do if needed. |
| [18:22:10] | stuartm: | although it would necessarily change the way some things are displayed, the background loading stuff used now does at least let us do swanky effects like showing the busy popup I just committed |
| [18:22:39] | stuartm: | which btw I wasn't wedded to, it was just a visual improvement on what already existed |
| [18:23:19] | stuartm: | I don't personally like to over-rely on javascript tricks to do what could just as easily be done with plain html |
| [18:24:24] | dblain: | agreed. The only think I was looking for was to be able to have a direct url. |
| [18:24:33] | stuartm: | dblain: I was going to check on includes anyway as I wanted to use them to improve the way the guide is handled |
| [18:24:33] | dblain: | s/think/thing |
| [18:24:57] | stuartm: | direct urls are good – can't bookmark a page with what we've got now |
| [18:25:06] | dblain: | I think I have my database up and running again so If you need help adding support, let me know. |
| [18:26:45] | ** dblain was at least able to test mythtv-setup, mythfilldatabase & mythbackend on windows as if I was a new user again (trying to look on positive side of database corruption... nope, not working) ** | |
| [18:27:18] | stuartm: | I couldn't help thinking there was something slightly farsical with the guide – it relies on four different languages (if you count markup as a language, and dinstinguish between server side ecma script and client side javascript) |
| [18:27:48] | stuartm: | dblain: ouch! At least I was able to recover, did you not have any of the automated backups around? |
| [18:28:43] | dblain: | stuartm: I did have backups, but for this instance of mythconverg it was only for developing on windows, so starting fresh didnt hurt too bad. |
| [18:35:14] | stuartm: | Need to spend some time reading up on the WebSocket API for HTML5. Having mythevents passed through to the browser would be great – automatically updating the guide to reflect recording status, the recording list when recordings start etc |
| [18:36:19] | ** dblain noticed commits on the torc project that adds WebSocket support ** | |
| [18:39:41] | stuartm: | I don't think it would require any special code in MythTV, we just connect to the backend specifying just as a frontend would to get access to the events |
| [18:40:02] | stuartm: | admittedly they would be in myth protocol format, but that's not difficult to parse |
| [18:41:22] | stuartm: | might be able to knock up a proof of concept tonight |
| [18:41:49] | stuartm: | the stuff I was just looking at seems straightforward enough |
| [18:42:54] | dblain: | Not sure of the limitations the spec introduces. If it's any type of socket connection to the hosting server, then your appoach may work |
| [18:43:35] | dblain: | But it would mean having to build support for mythprotocol in javascript |
| [18:46:44] | stuartm: | yeah, it's not as pretty but it has the benefit of being quick – we could instead have it connect to 6544 with SUBSCRIBE and then route myth events out over that in json or xml, would involve a little more work but it would be consistent with the rest of the services stuff |
| [18:49:02] | stuartm: | iirc httprequest does already support SUBSCRIBE so it's halfway there |
| [18:51:44] | stuartm: | tokenising the events is the labour intensive part – we'd need prototypes for all the existing events |
| [18:53:58] | dblain: | Not sure it supports SUBSCRIBE the way WebSockets needs it to. The support currently in httprequest is for upnp GINA subscription standard. When an event is fired, the backend makes a http call to the subscribed client url. |
| [18:54:54] | dblain: | I'd need to review the spec. I know very little about the mechanics of WebSocket. |
| [18:54:56] | stuartm: | dblain: ah, guess I assumed it maintained an open socket |
| [18:55:48] | stuartm: | only came across SUBSCRIBE for the first time when reading through the upnp docs, didn't read the specifics, just assumed |
| [18:58:31] | stuartm: | getting ahead of myself (again), there are a few other things that need to be done first |
| [18:59:19] | dblain: | Same here. I still need to change the parameters to be case insensitive and remove exceptions :/ |
| [19:00:06] | stuartm: | sphery: we've discussed in the past storing season/episode as seperate fields in the database before, any (good) reason not to do that and deprecate syndicatedEpisode? |
| [19:16:55] | sphery: | stuartm: syndicated episode number is totally different from broadcast or production season/episode number... we need to add user-editable fields for season and episode |
| [19:17:12] | sphery: | not replace syndicated |
| [19:19:17] | stuartm: | sphery: ok, won't replace it then |
| [19:19:36] | sphery: | in xmltv terms, syndicated episode number is <episode-num system="onscreen"> whereas the ones you want are <episode-num system="xmltv_ns"> |
| [19:19:45] | sphery: | see http://xmltv.cvs.sourceforge.net/viewvc/xmltv/xmltv/xmltv.dtd |
| [19:22:06] | stuartm: | I intend adding columns for broadcastEpisode, broadcastSeason and pushing what we get from xmltv and EIT there – both for display in the UI and as a default for the artwork grabbers (users can override if necessary) |
| [19:22:12] | sphery: | (that said, xmltv parser may stick xmltv_ns numbers into syndicated episode number or something (since that's all we have), but it shouldn't be doing so |
| [19:22:27] | stuartm: | sphery: that's exactly what it does |
| [19:22:35] | stuartm: | hence the confusion |
| [19:22:42] | sphery: | yeah, so if you could fix that and move them to the new ones, that would be great |
| [19:23:25] | sphery: | a lot of non-US developers of 3rd party apps have tried parsing values out of syndicated episode number thinking it means something it doesn't |
| [19:23:47] | sphery: | so would be good to have "real" places for season/episode num |
| [19:24:47] | dblain: | stuartm: FYI – you may need to escape special char in the program guide. it's loosing its mind formatting once it hits one. |
| [19:25:17] | sphery: | should we actually call it broadcast though? as even broadcast has multiple meanings--original broadcast order by original network vs order they're broadcast on other networks (i.e. if other networks broadcast them in "real" order or something, or if syndicated broadcast order is different or ...) |
| [19:25:18] | stuartm: | dblain: good point, forgot about that |
| [19:26:05] | sphery: | I'd almost think just calling it seasonnumber and episodenumber would be best since it's not making any promises :) |
| [19:26:48] | stuartm: | sphery: I was originally going to call it just season/episode but decided that would be confusing since we have a season/episode in recorded already (my new columns are going in program/recordedprogram) |
| [19:27:28] | stuartm: | broadcastEpisode just seemed to fit with the source of that numbering which is guide data, i.e. it reflects the broadcast order |
| [19:27:32] | warped_ (warped_!~piotro@89-79-251-78.dynamic.chello.pl) has joined #mythtv | |
| [19:28:24] | sphery: | I'd think it would be fine to have the same name for them, even though the recorded ones are the user-editable ones and the program ones would be the listings-provider ones |
| [19:30:42] | stuartm: | well as long as it stays that way, we don't want the confusion of third parties putting the wrong order in there and then having users wondering why their episodes of Friends are ordered incorrectly in Watch Recordings (i.e. not in broadcast order) |
| [20:00:04] | skd5aner: | stuartm: I think it's happening again (fluttering of mythbackend / socket issues) – however I'm about to walk out the door and I have babysitters over right now who are going to wonder why the TV doesn't work – bad timing :S |
| [20:02:22] | skd5aner: | I'll get back with you about it later |
| [20:07:41] | warped_ (warped_!~piotro@89-79-251-78.dynamic.chello.pl) has quit (Quit: warped_) | |
| [20:11:11] | dekarl1: | stuartm, sphery... hmm, depending more on the series/season/episode data model then less is not so nice :( Imho its broken and mostly enforced by the "give me pictures for my downloads" groups. All others just follow their lead. I'd prefer proper unique ids for episodes, as seen on imdb/thetvdb/atlas with the old-school season number and episode number added optionally. |
| [20:11:14] | dekarl1 is now known as dekarl | |
| [20:11:26] | joki (joki!~joki@p54862665.dip0.t-ipconnect.de) has quit (Ping timeout: 256 seconds) | |
| [20:11:31] | dekarl: | both thetvdb and themoviedb store imdb ids, might also include them :) |
| [20:12:08] | dekarl: | But I do understand that we don't have anything better then plain old s01e02 stuff atm |
| [20:12:50] | stuartm: | dekarl: for me the primary reason for storing that information is so that we can show it in the UI to inform the user, I quite often wonder how many episodes into a season I am and how many there are total, but although we receive that data from some xmltv and EIT sources it's just ignored |
| [20:13:35] | stuartm: | using it as a jumping off point for the artwork lookup is just an additional benefit |
| [20:14:59] | stuartm: | we can also optionally use it to offer 'viewing order' sorting in watch recording, so even if episodes are recorded out of sequence (can happen if it records a repeat) they will be presented in the correct order |
| [20:16:06] | dekarl: | sounds good |
| [20:16:46] | dekarl: | but judging from the discussions on thetvdb its sometimes hard to come up with *one* order :) |
| [20:16:57] | joki (joki!~joki@p548619BC.dip0.t-ipconnect.de) has joined #mythtv | |
| [20:17:33] | sphery: | yeah, and I see this as (for recorded shows) a user-editable ordering mechanism (and since we don't get an IMDB ID or anything with listings and it doesn't make sense to look up the ID for every show in everyone's listings, it's just properly storing a value that already exists in listings info) |
| [20:18:16] | sphery: | and because it's user editable, we don't have to have one order--we start with the order the listings data provides and users change it |
| [20:18:34] | sphery: | ("it is" user editable may be read "will be") |
| [20:19:18] | sphery: | but I don't think it makes sense to try to store multiple season/episode #'s, so having one that the user can update seems best to me |
| [20:39:54] | stichnot: | stuartm: don't forget to update the DB version in the perl and python bindings, or else e.g. mythweb will break (unless that's your intention :) ) |
| [20:42:46] | stuartm: | grr, sooner those are converted to use the services API the better :) |
| [20:43:20] | stuartm: | well except mythweb, I don't mean to intentionally break it, but since it's unmaintained ... |
| [20:52:50] | SteveGoodey (SteveGoodey!~steve@host86-134-193-50.range86-134.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [20:55:30] | gregL_ (gregL_!~greg@cpe-74-76-105-205.nycap.res.rr.com) has quit (Quit: Leaving) | |
| [20:56:33] | Jordack (Jordack!~Jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit () | |
| [21:01:07] | dekarl: | stuartm, btw, mind flipping around E02S01 in syndicatedepisodenum? |
| [21:03:55] | stuartm: | do I mind if it's done, or do I mind doing it? |
| [21:18:51] | dekarl: | do you know a reason that is the other way around of the sommon S%02dE%02d that I often see that would make someone want to revert it if I do what I'd call "fixing it" ;) |
| [21:19:30] | dekarl: | oh my... s/that is/that its/ s/sommon/common/ |
| [21:23:32] | stuartm: | dekarl: no idea |
| [21:23:52] | stuartm: | no special reason that I know of, it's not even used |
| [21:24:25] | dekarl: | hmm, I'm just seeing it in mythweb every now and then and wonder why its this way around |
| [21:36:06] | stuartm: | I can fix it, although it's redundant now |
| [21:39:07] | dekarl: | it was more a curiosity thing. I don't want to distract you from the backend webserver :) So I can do it, too |
| [21:44:33] | stuartm: | the backend webserver is distracting me from the image gallery work, which was distracting me from the upnp work |
| [21:44:57] | stuartm: | so one more thing wouldn't seem to make much difference :) |
| [21:55:45] | sphery: | dekarl: with the change stuartm just put in any xmltv_ns episode_num from XMLTV data should be stored in season and episode columns, and syndicatedepisodenum should *only* be populated with onscreen episode_num data |
| [21:56:42] | sphery: | syndicatedepisodenum should only be populated with the, er, syndicated episode number (the episode number used by the production company--which has no set format) |
| [21:57:39] | stuartm: | sphery: ah, well I left it sticking the data in synepnum for now, and even swapped it around just for Karl |
| [21:58:10] | stuartm: | once I've got it so that season/episode are displayed in the UI I'll remove that from the xmltv parser |
| [21:58:35] | dekarl: | hmm, so the episode system "onscreen" goes to syndicated?`http://xmltv.spaetfruehstuecken.org/xmltv/com . . . 11-12.xml.gz |
| [21:58:52] | sphery: | ideally we'd check the system specified in the xmltv data and populate synepnum if system == "onscreen" and populate season/episode if system = "xmltv_ns" |
| [21:59:25] | dekarl: | sphery, notice that both often come in pairs, see the link I just posted |
| [21:59:26] | stuartm: | sphery: we're already checking the system and only inserting synepnum if the system is _ns |
| [22:00:06] | stuartm: | nothing gets inserted into synepnum if the system is onscreen (or dd_progid) |
| [22:00:12] | sphery: | yeah, because the xmltv parser abuses synepnum, so I suppose it chose to at least make the data consistent |
| [22:01:04] | stuartm: | I'll swap that around, but as I said, I'll wait until the UI parts are done so that people don't complain the information isn't displayed anymore |
| [22:01:06] | sphery: | but now that we have everything in place, dd_progid should go to program (and can be truncated for seriesid) and onscreen to syndicatedepisodenum and xmltv_ns to season/episode |
| [22:01:17] | sphery: | thanks... |
| [22:01:31] | sphery: | wasn't trying to insist that you do it, but just insisting that one of us should do so one day |
| [22:02:01] | stuartm: | it's easy enough for me to do it while I'm working in that area |
| [22:02:34] | sphery: | I'm wondering if I'll get a chance to make more time for MythTV after Feb--after the wedding is over--or if I'll end up making even less time... :( |
| [22:02:39] | stuartm: | I'm only doing this now because I wanted to display the season/episode information in the internal webserver guide :) |
| [22:02:47] | dekarl: | how about system="themoviedb.org" or similar... with the recent addition of series with colliding ids (season and episode appear to be without their own id from the gui) |
| [22:03:04] | sphery: | I let real life get in the way of MythTV--sorry to let the community down |
| [22:03:19] | stuartm: | dekarl: well if you can get it accepted into the xmltv dtd :) |
| [22:03:22] | dekarl: | I can just write a pseudo url into it, like https://www.themoviedb.org/movie/49521 |
| [22:03:43] | dekarl: | stuartm. its already there :D |
| [22:03:53] | stuartm: | not the DTD I'm looking at :) |
| [22:03:55] | sphery: | according to the DTD, the only pre-defined systems are onscreen and xmltv_ns... I'm not sure if dd_progid is actually "standard" or more just something that's being used |
| [22:04:17] | stuartm: | http://xmltv.cvs.sourceforge.net/viewvc/xmltv/xmltv/xmltv.dtd |
| [22:04:31] | dekarl: | "But if you want, you can use your own system and give the 'system' attribute as a URL describing the system you use." |
| [22:05:27] | stuartm: | sphery: Robert Eden wrote the _dd grabber, if it was used there, I guess you could call it official |
| [22:05:34] | stuartm: | dekarl: fair enough |
| [22:05:35] | sphery: | wouldn't season and episode come from ttvdb.com, not tmdb.org? |
| [22:06:08] | sphery: | that said, that would only ever be used in recorded, and at the point it's in recorded, it's user-editable data |
| [22:06:12] | dekarl: | sphery ahh, you have not followed themoviedb closely in the last 10 days :) http://www.themoviedb.org/account/TheTVDB%20Bot |
| [22:06:45] | stuartm: | dekarl: the only reason I'd like for it to be in the DTD is to enforce a standard on all grabber devs, they could all incorporate the same id but use different names for the system |
| [22:06:58] | dekarl: | I'm fixing data sets on themoviedb.org every other evening so I can related them to my guide input |
| [22:07:32] | sphery: | ah, ok... I didn't think any guide would use those sources |
| [22:07:40] | sphery: | and cool about ttvdb being on tmdb |
| [22:07:43] | dekarl: | stuartm, fair enough. but someone has to propose something... |
| [22:08:01] | stuartm: | the DTD is the bible, by which I mean the big heavy book I use to beat non-compliant grabber devs with |
| [22:08:29] | dekarl: | sphery: I not sure... its an old version and it has different ids, so its more like seeding the new tv section with some data |
| [22:08:59] | sphery: | cool |
| [22:09:14] | sphery: | would be nice if they combined, even |
| [22:09:51] | dekarl: | actually I'd prefer to extend musicbrainz for their better editing process and flexible data model, but beggars can't be choosers |
| [22:10:03] | dekarl: | shuffling ids around sucks for people like http://fanart.tv/ |
| [22:10:27] | dekarl: | also they are balkanizing the community for unknown reasons |
| [22:10:40] | stuartm: | I'm not sure whether tmdb importing the tvdb data is a good thing – one of those sources is going to better maintained than the other, if it's tmdb that's great but somehow I doubt it since tvdb has all the existing and dedicated user/contributor base |
| [22:12:36] | stuartm: | and that's the evening gone, didn't get to touch the WebSocket stuff :( |
| [22:13:19] | dekarl: | fanart.tv and atlas are to good reasons to look at thetvdb instead... system="thetvdb.com" is a no brainer, but what to stick in there? the url without language? http://www.thetvdb.com/?tab=episode&serie . . . mp;id=339444 |
| [22:14:02] | jpabq (jpabq!~quassel@mythtv/developer/jpabq) has quit (Remote host closed the connection) | |
| [22:15:41] | dekarl: | that would allow to use e.g. http://www.thetvdb.com/?tab=series&id=80719 to signal a generic episode |
| [22:17:41] | jpabq (jpabq!~quassel@174-28-147-195.albq.qwest.net) has joined #mythtv | |
| [22:17:41] | jpabq (jpabq!~quassel@mythtv/developer/jpabq) has joined #mythtv | |
| [22:17:41] | jpabq (jpabq!~quassel@174-28-147-195.albq.qwest.net) has quit (Changing host) | |
| [22:25:17] | stuartm: | the only danger there is that they change their url system, breaking whatever we have stored in the database |
| [22:26:25] | stuartm: | I'm surprised they haven't followed the current trend for applying mod_rewrite to query strings so your example becomes http://www.thetvdb.com/episode/seriesid/80719 . . . 36/id/339444 or similar |
| [22:26:26] | dekarl: | it doesn't have to be their real url system. that would be just for convenience, but if they keep the same numbers we could just keep using their "old" url scheme |
| [22:27:10] | dekarl: | hmm, we could just directly go to a $hostname/series/$id/season/$id/episode/$id scheme |
| [22:28:06] | dekarl: | similar to the new https://www.themoviedb.org/tv/1396-breaking-b . . . 5/episode/16 |
| [22:28:40] | dekarl: | I'd fake that to https://www.themoviedb.org/tv/1396/season/5/episode/16 which works to, but is less likely to change due to fixed typos |
| [22:32:23] | stuartm: | the latter should incidentally work just like the original, such is the way most rewrite rules are written, they strip the useless stuff which is only inserted to give users a string they can relate to better |
| [22:32:45] | stuartm: | yup, click on it and it does indeed go to the correct page :) |
| [22:34:40] | dekarl: | well, imho its SEO spam... I usually make fun of it by adding a naughty fake title to news articles in the URL :) |
| [23:13:49] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!) | |
| [23:14:06] | NightMonkey (NightMonkey!~NightrMon@173-164-139-193-SFBA.hfc.comcastbusiness.net) has joined #mythtv | |
| [23:14:07] | NightMonkey (NightMonkey!~NightrMon@173-164-139-193-SFBA.hfc.comcastbusiness.net) has quit (Changing host) | |
| [23:14:07] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [23:23:08] | nvzn (nvzn!~nvzn@unaffiliated/nvzn) has joined #mythtv | |
| [23:32:53] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 272 seconds) | |
| [23:55:06] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [23:59:04] | nvzn_ (nvzn_!~nvzn@unaffiliated/nvzn) has joined #mythtv | |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.
