| Friday, January 7th, 2011, 00:07 UTC | ||
| [00:07:32] | rooaus: | stuartm: I haven't been tracking SVN for a while. The multiple wc rename thing is an awesome improvement, suspect it will need updated server though. SVN didn't have a native rename but used a delete+add internally which caused this limitation. |
| [00:16:05] | laga__ (laga__!~laga@h1626373.stratoserver.net) has joined #mythtv | |
| [00:22:30] | MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [00:25:04] | XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 248 seconds) | |
| [00:26:42] | laga__ is now known as laga | |
| [00:55:30] | XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [00:58:08] | MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 248 seconds) | |
| [01:36:20] | davide (davide!~david@host137.12.intrusion.com) has joined #mythtv | |
| [01:40:22] | gigem_ (gigem_!~david@host137.12.intrusion.com) has quit (Ping timeout: 255 seconds) | |
| [02:11:35] | MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [02:14:24] | XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 248 seconds) | |
| [02:22:10] | XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [02:25:04] | MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 248 seconds) | |
| [03:17:02] | NightMonkey (NightMonkey!debian-tor@pdpc/supporter/professional/nightmonkey) has quit (Ping timeout: 240 seconds) | |
| [03:18:28] | MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [03:21:36] | XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 248 seconds) | |
| [03:57:15] | Computer_Czar (Computer_Czar!phoenix@69.4.155.83) has joined #mythtv | |
| [03:57:58] | XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [04:00:32] | MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 248 seconds) | |
| [04:03:17] | Computer_Czar (Computer_Czar!phoenix@69.4.155.83) has quit (Quit: Leaving) | |
| [04:03:37] | Computer_Czar (Computer_Czar!~Unknown@69.4.155.83) has joined #mythtv | |
| [04:08:46] | Computer_Czar (Computer_Czar!~Unknown@69.4.155.83) has quit (Quit: Leaving for a long time ... see you later!) | |
| [04:30:39] | Dave123-road (Dave123-road!~dave@cpe-74-74-222-96.rochester.res.rr.com) has quit (Quit: Leaving) | |
| [04:43:16] | Dave123-road (Dave123-road!~dave@cpe-74-74-222-96.rochester.res.rr.com) has joined #mythtv | |
| [05:13:02] | j-rod|afk (j-rod|afk!~jarod@static-72-93-233-2.bstnma.fios.verizon.net) has quit (Ping timeout: 240 seconds) | |
| [05:18:47] | j-rod|afk (j-rod|afk!~jarod@static-72-93-233-2.bstnma.fios.verizon.net) has joined #mythtv | |
| [05:41:50] | knightr (knightr!~knightr@mythtv/developer/knightr) has quit (Read error: Connection reset by peer) | |
| [05:42:17] | knightr (knightr!~knightr@mythtv/developer/knightr) has joined #mythtv | |
| [06:30:43] | dingus (dingus!~bill@ppp121-44-103-215.lns20.syd6.internode.on.net) has joined #mythtv | |
| [06:31:16] | dingus: | hey not a development question, but i had a rat thorugh the websie, and i cant find a way to donate to mythtv, i figured asking the developers might be the best approach to figureing that out |
| [06:33:24] | wagnerrp: | patches and code, the project does not accept monetary donations |
| [06:33:52] | wagnerrp: | or if you prefer, documentation, or translation, or just hang out and help on the mailing list or irc channel |
| [06:34:20] | clever: | what about paying a friend to fix tickets? :P |
| [06:34:36] | clever: | he isnt part of the project |
| [06:34:46] | jya (jya!~avenardj@mythtv/developer/jya) has quit (Quit: jya) | |
| [06:39:04] | dingus: | fair enough any reasion the project dose not accept monetary donations? |
| [06:45:47] | wagnerrp: | primarily fear of becoming a legal target |
| [06:47:10] | dingus: | fair call well i just personally really appriceate the software and the help i get in irc, so anything i can do to help i would be happy to |
| [06:48:42] | wagnerrp: | http://mythtv.org/wiki/Contribute |
| [07:08:02] | jya (jya!~avenardj@mythtv/developer/jya) has joined #mythtv | |
| [07:27:02] | wagnerrp is now known as Beirc1o | |
| [07:27:18] | Beirc1o is now known as wagnerrp | |
| [07:29:29] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [07:40:22] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 255 seconds) | |
| [07:53:33] | sphery (sphery!~mdean@mythtv/developer/sphery) has quit (Ping timeout: 240 seconds) | |
| [08:00:38] | Kunalagon (Kunalagon!~Kunalagon@212.200.241.4) has joined #mythtv | |
| [08:01:36] | stuartm_ (stuartm_!~stuartm@mythtv/developer/stuartm) has joined #mythtv | |
| [08:02:00] | stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has quit (Ping timeout: 240 seconds) | |
| [08:23:01] | duerF (duerF!~tommi@heima.tommi.org) has quit (Quit: Leaving) | |
| [08:24:09] | stoffel (stoffel!~quassel@p57B4CDC2.dip.t-dialin.net) has joined #mythtv | |
| [08:33:18] | Goga777 (Goga777!~Goga777@shpd-92-101-136-20.vologda.ru) has joined #mythtv | |
| [08:56:52] | highzeth (highzeth!~hz@hoiseth.no) has quit (Ping timeout: 255 seconds) | |
| [09:10:09] | highzeth (highzeth!~hz@hoiseth.no) has joined #mythtv | |
| [09:13:43] | dingus (dingus!~bill@ppp121-44-103-215.lns20.syd6.internode.on.net) has quit (Read error: Connection reset by peer) | |
| [09:13:51] | dingus (dingus!~bill@ppp121-44-103-215.lns20.syd6.internode.on.net) has joined #mythtv | |
| [09:29:19] | balor (balor!~aidan@87.127.55.57) has joined #mythtv | |
| [09:43:26] | jya (jya!~avenardj@mythtv/developer/jya) has quit (Quit: jya) | |
| [09:46:01] | andreax1 (andreax1!~andreaz@p57B95A89.dip.t-dialin.net) has quit (Read error: Connection reset by peer) | |
| [10:23:05] | MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [10:26:08] | XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 248 seconds) | |
| [10:26:18] | stuartm_ is now known as stuartm | |
| [10:28:09] | jamesba (jamesba!~jamesba@gateb.kw.bbc.co.uk) has joined #mythtv | |
| [10:31:31] | stoffel (stoffel!~quassel@p57B4CDC2.dip.t-dialin.net) has quit (Ping timeout: 272 seconds) | |
| [11:07:11] | simonckenyon (simonckenyon!~simoncken@195.7.61.12) has joined #mythtv | |
| [11:10:24] | Goga777 (Goga777!~Goga777@shpd-92-101-136-20.vologda.ru) has quit (Remote host closed the connection) | |
| [11:13:02] | stoffel (stoffel!~quassel@p57B4CDC2.dip.t-dialin.net) has joined #mythtv | |
| [11:18:51] | antifoo (antifoo!~antifoo@123.200.143.227) has quit (Quit: antifoo) | |
| [11:19:13] | Stevezau (Stevezau!~Stevezau@60-242-114-18.static.tpgi.com.au) has joined #mythtv | |
| [11:36:37] | highzeth (highzeth!~hz@hoiseth.no) has quit (Ping timeout: 255 seconds) | |
| [11:37:51] | highzeth (highzeth!~hz@hoiseth.no) has joined #mythtv | |
| [12:10:43] | simonckenyon (simonckenyon!~simoncken@195.7.61.12) has quit (Remote host closed the connection) | |
| [12:11:16] | jya (jya!~avenardj@mythtv/developer/jya) has joined #mythtv | |
| [12:15:28] | simonckenyon (simonckenyon!~simoncken@195.7.61.12) has joined #mythtv | |
| [12:16:27] | kenni (kenni!~kenni@pfsense.dhcp.pop.k-net.dk) has quit (Read error: Operation timed out) | |
| [12:36:36] | gigem_ (gigem_!~david@host137.12.intrusion.com) has joined #mythtv | |
| [12:40:25] | davide (davide!~david@host137.12.intrusion.com) has quit (Ping timeout: 246 seconds) | |
| [12:41:19] | Stevezau (Stevezau!~Stevezau@60-242-114-18.static.tpgi.com.au) has quit () | |
| [12:45:36] | kenni (kenni!~kenni@pfsense.dhcp.pop.k-net.dk) has joined #mythtv | |
| [12:48:16] | XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [12:48:46] | jya (jya!~avenardj@mythtv/developer/jya) has quit (Quit: jya) | |
| [12:51:12] | MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 248 seconds) | |
| [13:10:47] | balor (balor!~aidan@87.127.55.57) has quit (Read error: Operation timed out) | |
| [13:13:26] | MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [13:16:16] | XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 248 seconds) | |
| [14:07:25] | Gibby (Gibby!~Gibby@204.118.10.244) has quit (Ping timeout: 255 seconds) | |
| [14:13:15] | Gibby (Gibby!~Gibby@204.118.10.244) has joined #mythtv | |
| [14:28:33] | stoffel (stoffel!~quassel@p57B4CDC2.dip.t-dialin.net) has quit (Ping timeout: 240 seconds) | |
| [14:30:58] | XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [14:34:08] | MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 248 seconds) | |
| [14:38:48] | j-rod|afk is now known as j-rod | |
| [14:42:08] | MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [14:43:57] | j-rod: | superm1: I've not filed a bug myself for lirc. I had recollections of someone saying it couldn't be updated, but maybe that was only a release freeze issue |
| [14:44:08] | j-rod: | if so though, I'd have expected it to be updated by now |
| [14:44:48] | XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 248 seconds) | |
| [15:00:03] | doc (doc!~bill@ppp121-44-39-92.lns20.syd6.internode.on.net) has joined #mythtv | |
| [15:01:10] | balor (balor!~aidan@87.127.55.57) has joined #mythtv | |
| [15:01:16] | dingus (dingus!~bill@ppp121-44-103-215.lns20.syd6.internode.on.net) has quit (Ping timeout: 276 seconds) | |
| [15:05:21] | XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [15:08:16] | MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 248 seconds) | |
| [15:09:24] | sphery (sphery!~mdean@mythtv/developer/sphery) has joined #mythtv | |
| [15:12:36] | balor_ (balor_!~aidan@87.127.55.57) has joined #mythtv | |
| [15:12:51] | balor (balor!~aidan@87.127.55.57) has quit (Read error: Connection reset by peer) | |
| [15:16:58] | PointyPumper (PointyPumper!~pintlezz@190.244.73.13) has quit (Ping timeout: 265 seconds) | |
| [15:25:36] | MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [15:28:19] | stuartm: | anyone interested in debugging upnp/ssdp related problems? One issue in particular is causing me a lot of problems in testing the mythui port of the backend selection screen, I have a 0.23 backend on the network which responds to initial requests from a trunk frontend but then doesn't answer "getDeviceDesc" calls, the frontend continually retries blocking the UI for at least 40 seconds |
| [15:28:32] | XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 248 seconds) | |
| [15:36:43] | XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [15:37:31] | stuartm: | I can just reduce the timeout from 10 seconds and disable the retries, but that's a hack and would probably have knock on effects, or I could handle this all on the UI end, move the device description calls into their own thread and that's probably worth doing anyway, but it also ignores the core issue |
| [15:39:44] | MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 248 seconds) | |
| [15:40:27] | dblain_: | I agree the requests should be in a background thread. Have you tried making the getDeviceDesc call from wget or a browser? |
| [15:41:02] | dblain_: | That would at least show if it's the new ui changes or the backend that is having the problem. |
| [15:43:31] | danielk22: | stuartm: hmm, I've made some improvements to UPnP in the mythtv-rec branch. I'd recommend trying it except it has a db update for additional recorders.. |
| [15:48:39] | superm1: | j-rod, that was a release freeze issue. i dont think anyone's actually requested to pull in the update, so it hasn't happened yet. updates dont just happen on stable release unless people file bugs complaining about what the update needs to bring in |
| [15:50:47] | stuartm: | dblain_: I don't know why, but I never checked the most obvious factor – that mythbuntu backend had a firewall running that I didn't know about ... just call me an idiot |
| [15:51:20] | dblain_: | We've all been there! Glad it was an easy fix. |
| [15:51:45] | dblain_ is now known as dblain | |
| [15:51:47] | stuartm: | I'll move the calls into a thread though, because I won't be the only person bitten by this |
| [15:52:01] | dblain (dblain!~dblain@c-76-127-227-175.hsd1.ma.comcast.net) has quit (Changing host) | |
| [15:52:01] | dblain (dblain!~dblain@mythtv/developer/dblain) has joined #mythtv | |
| [15:52:12] | dblain: | Agreed. |
| [15:52:39] | stuartm: | danielk22: looks like I won't need those improvements for now, but I look forward to seeing them |
| [15:56:08] | stuartm: | danielk22, dblain: One improvement I wouldn't mind is the discovery code looking for a backend on the current machine directly (pinging the usual ports or whatever), I did find that on a combined fe/be with firewall (imagine a single network, no router) that SSDP fails and the user is told we can't find any backend |
| [15:58:22] | dblain: | My new changes to the http server (which upnp uses) allows for a list of ip:ports to listen and advertise on. Not sure if it would solve the problem, but if localhost as added as a address to use, it may work. |
| [15:58:28] | stuartm: | in that case it seems like we could find the backend and connect automatically all the same, but it doesn't work out that way, at least not in the initial backend selection ... still I can deal with that later |
| [15:58:48] | j-rod: | superm1: can an update be done just for my sanity? :) |
| [15:59:15] | j-rod: | even yesterday, in #lirc, "hi, I just upgraded to lirc 0.8.7-pre3"... |
| [15:59:20] | dblain: | stuartm: I'd be curious to see if setting your IP address to 127.0.0.1 would allow it to find the backend. |
| [16:01:05] | stuartm: | dblain: I might just try that tomorrow :) |
| [16:13:44] | AriX (AriX!~Ari@c-76-99-118-183.hsd1.pa.comcast.net) has joined #mythtv | |
| [16:16:19] | AriX (AriX!~Ari@c-76-99-118-183.hsd1.pa.comcast.net) has quit (Remote host closed the connection) | |
| [16:16:41] | AriX (AriX!~Ari@c-76-99-118-183.hsd1.pa.comcast.net) has joined #mythtv | |
| [16:17:36] | AriX (AriX!~Ari@c-76-99-118-183.hsd1.pa.comcast.net) has quit (Client Quit) | |
| [16:22:37] | elmojo: | Thank you, Michael Niedermayer! |
| [16:25:13] | iamlindoro: | heh, for which part? |
| [16:25:13] | elmojo: | he just posted patches that deprecate reordered_opaque timestamps – which means I should be able to get rid of all the hackish timestamp handling |
| [16:25:13] | iamlindoro: | oh, Yeah, I saw those |
| [16:25:13] | iamlindoro: | yeah, that's nice |
| [16:25:13] | elmojo: | didn't really like that the player had to handle that decision |
| [16:25:19] | elmojo: | we'll still use reordered_opaque for the private_decoder most likely |
| [16:26:29] | stoffel (stoffel!~quassel@p57B4CDC2.dip.t-dialin.net) has joined #mythtv | |
| [16:27:48] | MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [16:30:24] | XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 248 seconds) | |
| [16:48:44] | PointyPumper (PointyPumper!~pintlezz@190.244.73.13) has joined #mythtv | |
| [16:54:10] | Steve_Goodey (Steve_Goodey!~steve@host86-147-81-4.range86-147.btcentralplus.com) has joined #mythtv | |
| [17:01:14] | abqjp (abqjp!~abqjp@97-119-168-204.albq.qwest.net) has joined #mythtv | |
| [17:02:49] | Steve_Goodey (Steve_Goodey!~steve@host86-147-81-4.range86-147.btcentralplus.com) has quit (Remote host closed the connection) | |
| [17:34:44] | superm1: | j-rod, i'll file a bug and assign it to myself and see what i can do. i'll get it in natty first |
| [17:35:34] | j-rod: | superm1: cool. note that 0.9.0 is due out RSN though, would prefer that in the next release |
| [17:35:57] | j-rod: | I just need to see if I can fix lirc_serial tx first |
| [17:36:24] | davide (davide!~david@host137.12.intrusion.com) has joined #mythtv | |
| [17:36:37] | superm1: | plenty of time to pull in new versions in natty, so that shouldn't be trouble |
| [17:40:01] | gigem_ (gigem_!~david@host137.12.intrusion.com) has quit (Ping timeout: 246 seconds) | |
| [17:57:39] | stuartm: | not especially pretty, but an improvement on the existing screen – http://miffteevee.co.uk/imagebin/backendselection.png |
| [17:57:54] | iamlindoro: | nice |
| [17:58:10] | iamlindoro: | Select the server to which you wish to connect ;) |
| [17:58:41] | stuarta: | nice |
| [17:58:51] | stuartm: | yeah, not grammatically correct, it's a for demonstration purposes ;) |
| [17:59:23] | wagnerrp: | purty |
| [17:59:58] | stuartm: | need to extend the information returned from the frontends to include detail of whether they are pin protected, that bit doesn't work atm |
| [18:00:43] | ** stuarta won't mention the DB incompatibilities between versions.... :) ** | |
| [18:01:02] | wagnerrp: | stuartm: nah, just query the settings table entry over mythxml |
| [18:01:41] | wagnerrp: | http://<backend>:6544/Myth/GetSetting?K . . . ;backend> |
| [18:01:53] | stuarta: | excellent security model there.... |
| [18:01:54] | wagnerrp: | although IMHO, if youre getting rid of automatic connection in favor of a selection screen, the PIN can go away entirely |
| [18:02:13] | stuartm: | wagnerrp: too insecure (you shouldn't even be able to query that remotely) |
| [18:02:38] | stuartm: | wagnerrp: I'll just add a bool to the GetDeviceDesc response |
| [18:03:06] | stuartm: | wagnerrp: and no, if there is only one backend found we connect to that and bypass selection entirely |
| [18:03:25] | stuartm: | at least that's the theory |
| [18:04:19] | wagnerrp: | well its not like a 4-digit pin is secure anyway |
| [18:04:20] | wagnerrp: | i was under the impression it was merely supposed to prevent autoconnection when you had multiple master backends on the same network |
| [18:04:36] | wagnerrp: | it might be good to gray out servers which are a newer (and possibly older) version |
| [18:04:37] | stuartm: | no idea why we'd remove the pin, it's there precisely because if there are multiple backends on a network then chances are you don't want to allow everyone to connect to yours |
| [18:05:01] | wagnerrp: | because mythtv has no security |
| [18:05:12] | wagnerrp: | and if you find it, you can also ask the backend for the PIN in the same manner |
| [18:05:28] | stuartm: | wagnerrp: it's there to prevent children connecting to their parents mythbackend, or students connecting to another students backend on the uni network, or in a flat share etc |
| [18:05:36] | dserban (dserban!~dserban@S0106001346beb5f3.ok.shawcable.net) has joined #mythtv | |
| [18:05:37] | wagnerrp: | or even if you dont want to access the database, you can still rage wide destruction through the backend protocol alone |
| [18:05:49] | wagnerrp: | it only exists to keep a properly behaving frontend out |
| [18:05:58] | wagnerrp: | not to prevent someone from fiddling with your system |
| [18:06:00] | stuartm: | wagnerrp: yeah, you should not be able to query the security pin in that way, might be the time to remove it from the database |
| [18:06:48] | stuartm: | wagnerrp: nu-uh, it exists for the latter, just because the rest of the frontend security is piss-poor doesn't mean we should just give up on it |
| [18:07:30] | stuartm: | actually, we don't need to remove it from the database, just stop mythxml from handing it out on request |
| [18:07:38] | ** stuartm goes to eat ** | |
| [18:07:51] | wagnerrp: | i dont see a need for it to be in the database |
| [18:08:00] | wagnerrp: | if you have access to the database already, you dont need the pin |
| [18:11:41] | wagnerrp: | either way, QUERY_RECORDINGS with DELETE_RECORDING can be used without knowledge of the database |
| [18:19:36] | jamesba (jamesba!~jamesba@gateb.kw.bbc.co.uk) has quit (Quit: Leaving) | |
| [18:19:45] | wagnerrp: | stuartm: we would also need to do a complete fuzzing test of the backend protocol if thats going to be a concern |
| [18:20:20] | wagnerrp: | i was trying to figure out how to get the paths of the non-recording storage groups through the backend protocol, so i could do QUERY_SG_FILELIST for a list, followed by DELETE_FILE |
| [18:20:44] | wagnerrp: | i thought an empty QUERY_SG_FILELIST would return the available storage groups and paths |
| [18:20:54] | wagnerrp: | turns out it just crashes the backend |
| [18:22:01] | wagnerrp: | although i understand what youre saying about possibly wanting to use it as a parental lockout between multiple systems |
| [18:22:23] | wagnerrp: | im just saying that it would be completely useless on a university network or the like |
| [18:23:59] | stuartm: | wagnerrp: the security pin was implemented because automatic discovery meant that any user, however non-technical they might be could connect to any backend on a network either deliberately or by accident and do real damage |
| [18:25:09] | wagnerrp: | right, im saying disable autodetection in the backend, and alter it in the frontend and bindings so it provides a selection screen of what available systems there are, no auto-selection |
| [18:25:40] | wagnerrp: | considering you only ever have to do it once after which such information gets stored to a local file |
| [18:26:24] | stuartm: | it's a weak measure, especially given the general insecurity of the protocol etc, but the other vectors of attack require at least some basic knowledge and skill with computers/http/xml/whatever |
| [18:27:02] | stuartm: | wagnerrp: simply making it a selection does nothing to address the concerns that caused it to be added in the first place |
| [18:27:32] | stuartm: | I'm for improving security not removing what little we already have |
| [18:30:11] | stuartm: | and yes, I've been wanting to do some fuzzing tests of the protocol and other bits of the code for a long time |
| [18:30:46] | Chutt: | that'll fail horribly :p |
| [18:30:47] | stuartm: | for stability reasons it should be done, if not because of the security concern |
| [18:30:48] | wagnerrp: | well either way, i dont see a purpose to store that value outside the mysql.txt/config.xml file |
| [18:31:07] | stuartm: | Chutt: aye, not much in the way of validation is done |
| [18:31:30] | wagnerrp: | theres a bit of validation on some of the functions dealing with file paths |
| [18:31:51] | wagnerrp: | and some portion of the functions fail if the correct number of values are not given |
| [18:31:56] | wagnerrp: | but most have none |
| [18:32:03] | stuartm: | wagnerrp: neither do I, I was just saying that it could be stored in the database if the database is theoretically secure – it should be, since we require the pin to get the db connection details |
| [18:32:12] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [18:32:53] | wagnerrp: | as part of trying to break out that if/elseif into loadable modules, i was going through and at least adding value count checks on everything |
| [18:33:06] | stuartm: | but it's perhaps much more secure stored elsewhere, where it can't be queried remotely in any way |
| [18:34:12] | wagnerrp: | but i got stalled on that a while back, i wanted to rethink how it was handled |
| [18:35:39] | XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [18:38:56] | MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 248 seconds) | |
| [18:53:40] | anykey_ (anykey_!~guedel@46-126-247-133.dclient.hispeed.ch) has quit (Read error: Operation timed out) | |
| [18:56:29] | MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [18:57:54] | anykey_ (anykey_!~guedel@46-126-247-133.dclient.hispeed.ch) has joined #mythtv | |
| [18:58:52] | dserban (dserban!~dserban@S0106001346beb5f3.ok.shawcable.net) has quit (Ping timeout: 250 seconds) | |
| [18:59:12] | XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 248 seconds) | |
| [19:15:05] | stoffel (stoffel!~quassel@p57B4CDC2.dip.t-dialin.net) has quit (Ping timeout: 264 seconds) | |
| [19:25:43] | balor_ (balor_!~aidan@87.127.55.57) has quit (Read error: Connection reset by peer) | |
| [19:26:07] | balor_ (balor_!~aidan@87.127.55.57) has joined #mythtv | |
| [19:32:14] | elmojo: | danielk22: wanted to know if you have any opinions on one of the player improvements I'm planning for this release which is to support byte seeking for containers with timestamp discontinuities (ie, MPEG-TS) – I hoping this speeds up seeking and corrects some videos where seeking is completely broken |
| [19:33:22] | danielk22: | elmojo: For when there is no seek map in the DB? How will you know there are timestamp discontinuities? |
| [19:33:37] | elmojo: | I'll have to do some refactoring in tv_play and mythplayer on how we signal a seek to the decoder class |
| [19:34:08] | elmojo: | the ffmpeg demuxer has a flag that tells you if the container supports timestamp discontinuities |
| [19:34:39] | elmojo: | I think it may just be MPEG-TS but that's a heavily used container (broadcast, bluray, etc) |
| [19:35:28] | Chutt: | heh, yay |
| [19:35:36] | Chutt: | "one of the most amazing things we've seen at ces" |
| [19:35:45] | Chutt: | err, "ever seen" |
| [19:35:46] | danielk22: | elmojo: but your typical MPEG-TS does not have timestamp discontinuities. Is there a broadcaster sending out bad streams? |
| [19:36:00] | wagnerrp: | Chutt: this something about the 'desktop tegra'? |
| [19:36:07] | Chutt: | naw, the at&t phone |
| [19:36:32] | laga: | made by HTC? |
| [19:36:55] | Chutt: | mot |
| [19:37:05] | danielk22: | ATRIX I assume |
| [19:37:06] | laga: | ah, yes. they have some nice gear this year. |
| [19:37:08] | Chutt: | yeah |
| [19:37:18] | Chutt: | the one with the laptop dock |
| [19:37:24] | skd5aner (skd5aner!~skd5aner@cpe-069-132-082-180.carolina.res.rr.com) has quit () | |
| [19:37:25] | laga: | i wonder if the bootloader will be locked ;) |
| [19:37:47] | elmojo: | danielk22: not that I'm aware and it's not to just fix timestamp discontinuities but to make seeking much faster and reliable... I've ran into recordings that I tried playing back without a posmap using the Internal player and a seek would freeze the player indefinitely – the av_seek_frame never returned – I hacked in byte seeking support and it worked correctly |
| [19:38:16] | balor_ is now known as balor | |
| [19:38:18] | elmojo: | it's what the ffmpeg devs use for ffplay too |
| [19:38:45] | elmojo: | I would hope it stops the seek to EOF several times behavior too |
| [19:39:43] | danielk22: | elmojo: hmm, well I'm for anything that will make the seeking faster.. but mark k has been maintaining the player code as of late. Try to sync with him so you're not heading in opposite directions. |
| [19:40:13] | elmojo: | heh, I think he leaves this stuff up to me – which probably isn't a good idea :) |
| [19:42:03] | danielk22: | The seek to end-of-file at the start of every seek is a major annoyance with the ffmpeg seeking. A little bit of caching there might speed things up without any major changes. i.e. if the seek is to a point before the previously discovered last pts don't seek to the end of the file to find it's pts<->byte mapping. |
| [19:42:31] | elmojo: | danielk22: ultimately tv_play/mythplayer needs to be sending how much time (in ms) we want to seek and which direction and let avformatdecoder handle the rest |
| [19:42:57] | wagnerrp: | instead of the current byte-seeking? |
| [19:43:01] | danielk22: | elmojo: well we also need frame by frame seeking for editing. |
| [19:44:08] | elmojo: | I don't like all the fact that we still use the frame number and fps to determine the seek time – it's wrong in certain cases |
| [19:45:07] | elmojo: | we need to store timecode and packet byte position for each video frame and store in the player so that the decoder when it receives a seek can get those values along with the seek amount/direction and do the correct thing |
| [19:45:51] | elmojo: | this will eliminate the problems with repeats,discontinuities, and frame rate changes – basically morphing the player into the modern age |
| [19:46:37] | elmojo: | plus, it will simplify the code (I think) :) |
| [19:47:23] | elmojo: | I don't think it's going to solve the fact that ffmpeg seeking misses the keyframe/IDR most of the time so you get corrupted playback until it hits one |
| [19:47:32] | elmojo: | that's beyond our control anyways |
| [19:47:49] | danielk22: | elmojo: people complain about the seekmap already being too large.. fps changes are rare enough that we can just note them separately and then throw some smarts at it. i.e. a class that presents this time-stame<->frame<->bytepos view to the player but uses a more compact and efficient internal storage. |
| [19:48:08] | danielk22: | s/stame/stamp/ |
| [19:49:32] | elmojo: | I think the design I have in my head will work with the existing infrastructure without adding a new class to support it |
| [19:49:57] | danielk22: | Anyway, I had plans to fix that years ago and never got to it.. more power to you if you do :) PS Everyone else will keep adding more code that assumes FPS is fixed while you work on it, or at least that was my experience. ;] |
| [19:50:14] | elmojo: | no doubt, it's everywhere |
| [19:50:45] | elmojo: | but I've already fixed the playback positioning and duration which has been a huge, persistent complaint over recent years |
| [19:51:50] | danielk22: | elmojo: yes, wasn't it ticket 880? |
| [19:52:41] | danielk22: | nah, but it was 8-something for years.. |
| [19:52:57] | elmojo: | yes, I never referenced or took the time to find it :) |
| [19:55:42] | Beirdo: | danielk22: I did come up with a method to build that earlier, but not sure how efficiently. QMap is skip-list based, so .find() should be pretty fast (and the find previous item/next item method) |
| [19:56:26] | Beirdo: | I'll defer to elmojo on the implementation, he's done a great job so far ;) |
| [19:57:13] | Beirdo: | but QMap used with find should be quite fast – O(log n). Linear searches via iterator not so much |
| [20:01:07] | elmojo: | ah, you guys are talking about seeking with a position map and I'm talking about seeking without a position map :) |
| [20:04:08] | Beirdo: | oh :) |
| [20:08:29] | stuartm: | dblain: the xml response to getDeviceDesc is part of the upnp standard and not something custom to MythTV? Any way we can include custom information in there without violating whatever schema/standard is followed? |
| [20:08:55] | elmojo: | danielk22: I could go ahead and easily add repeat counts to the frame number – but that would make the pre-existing position maps be out of sync |
| [20:09:04] | elmojo: | but it's the right thing to do |
| [20:09:30] | elmojo: | not sure how you correct issues like that without causing people to much trouble |
| [20:09:57] | Beirdo: | stuartm: that was my understanding, but dblain knows it better than I :) |
| [20:10:15] | stuartm: | dblain: specifically I'd like to include a boolean value indicating whether a Security Pin has been set for that machine and maybe the hostname too (which can be custom and not necessarily the same as the machines hostname) |
| [20:10:41] | Beirdo: | that would be cool |
| [20:11:12] | Beirdo: | I think the UPnP spec (rather than the DLNA superset) is freely available on the internet |
| [20:11:30] | stuartm: | I could of course add MythXML methods to fetch that info, but it's faster if the initial response contains everything we need |
| [20:11:52] | stuartm: | Beirdo: ah, I was under the impression that it was hard to come by |
| [20:12:10] | Beirdo: | I think Intel has UPnP ones up... I remember getting them |
| [20:12:15] | Beirdo: | DLNA... makes you pay |
| [20:13:03] | Beirdo: | it might be as simple as adding a custom namespace, but I'm not sure if that meets spec either |
| [20:13:32] | danielk22: | elmojo: You are thinking of the US where broadcasts are at ~30 or ~60 fps but only 24 frames are sent + repeat flags? That's one issue, another is places where the actual frame-rate changes for different programming. That's the case I was thinking of. |
| [20:13:33] | stuartm: | http://upnp.org/index.php/sdcps-and-certifica . . . dards/sdcps/ |
| [20:13:58] | danielk22 (danielk22!~danielk@96.57.9.142) has quit (Quit: Leaving.) | |
| [20:15:05] | Beirdo: | ahh, right on upnp.org, even easier :) |
| [20:15:42] | danielk22 (danielk22!~danielk@96.57.9.142) has joined #mythtv | |
| [20:15:50] | stuartm: | not well organised though, you have to know the spec to find the part of the spec you need ;) |
| [20:16:20] | Beirdo: | yeah, true |
| [20:16:32] | Beirdo: | mythbackend works as a MediaServer, IIRC |
| [20:16:47] | stuartm: | I've found it |
| [20:16:52] | Beirdo: | mythfrontend has some MediaRenderer stuff that markk was working on too, I think |
| [20:17:19] | Beirdo: | not sure which version of MediaServer we identify as though |
| [20:17:22] | Beirdo: | good :) |
| [20:18:24] | stuartm: | btw, we don't send any icons? That would be nifty |
| [20:19:26] | Beirdo: | I think we try, but we've never seemingly gotten it right |
| [20:19:32] | elmojo: | danielk22: yes, that last idea I proposed isn't a good idea... the right way to correct the problem is to use the currently displayed frames timecode or bytepos and not worry about frame number for non posmap seeking |
| [20:19:43] | Beirdo: | I would love to have previews pix working :) |
| [20:22:19] | fmilo (fmilo!~misto@64.17.253.218) has joined #mythtv | |
| [20:22:31] | stuartm: | ok, mediaserver docs aren't too detailed, on the one hand that makes them easily understood and readable, on the other it doesn't define clearly whether you can extend the device description |
| [20:23:06] | stuartm: | I think in the absence of a "you can insert your own stuff here" that you can't do that |
| [20:23:18] | Beirdo: | yeah, clear as mud :( |
| [20:23:38] | Beirdo: | maybe the "member documents" state it better |
| [20:24:02] | stuartm: | so maybe a custom 'mythxml/getMoreDeviceInfo' is the way to go |
| [20:24:14] | stuartm: | we'll be the only ones using that additional data anyway |
| [20:24:18] | Beirdo: | yeah |
| [20:25:18] | Beirdo: | likely the most cross-compatible method |
| [20:27:16] | stuartm: | I only want the information to help round out the UI a little, it's not critical to operation |
| [20:33:47] | Beirdo: | I look forward to seeing the results of this, particularly if it can show something that helps with upnp debugging and the like |
| [20:39:00] | stuartm: | it's little more than a port of the backend selection screen to mythui, I guess some of the new work has other applications, but it's nothing to get excited about |
| [20:40:09] | stuartm: | once complete it will clear some more warnings and enabled the removal of some old ui code, those are my only goals, anything else is a bonus |
| [20:40:58] | stuartm: | if the frontend ever has client capabilities added then we'll be able to re-use some of this |
| [20:53:50] | Beirdo: | yeah. |
| [20:53:54] | Beirdo: | still. nice |
| [21:03:32] | balor (balor!~aidan@87.127.55.57) has quit (Ping timeout: 240 seconds) | |
| [21:09:01] | andreax (andreax!~andreaz@p57B95A89.dip.t-dialin.net) has joined #mythtv | |
| [21:15:39] | andreax (andreax!~andreaz@p57B95A89.dip.t-dialin.net) has quit (Read error: Connection reset by peer) | |
| [21:16:58] | balor (balor!~aidan@87.127.55.57) has joined #mythtv | |
| [21:18:14] | dekarl1 (dekarl1!~deKarl@e180142058.adsl.alicedsl.de) has joined #mythtv | |
| [21:20:18] | NightMonkey (NightMonkey!debian-tor@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [21:21:01] | dekarl (dekarl!~deKarl@e180146242.adsl.alicedsl.de) has quit (Ping timeout: 276 seconds) | |
| [21:27:54] | balor (balor!~aidan@87.127.55.57) has quit (Ping timeout: 240 seconds) | |
| [21:31:01] | stuartm: | stuarta: I've been thinking about something that was said in -users earlier about the problems caused by EIT being collected on a channel for which we already have xmltv data |
| [21:32:22] | stuartm: | the solution is dead easy, disable EIT collection on a channel if there is an xmltvid defined _and_ data appears in the database for that channel – this allows EIT data to be used automatically should xmltv collection fail |
| [21:32:40] | stuartm: | as the EIT maintainer, what do you think of the idea? |
| [21:33:02] | fmilo (fmilo!~misto@64.17.253.218) has quit (Quit: fmilo) | |
| [21:48:26] | fmilo (fmilo!~misto@64.17.253.218) has joined #mythtv | |
| [21:56:08] | gnome42 (gnome42!~gnome42@69-165-160-245.dsl.teksavvy.com) has joined #mythtv | |
| [22:09:13] | gnome42 (gnome42!~gnome42@69-165-160-245.dsl.teksavvy.com) has left #mythtv () | |
| [22:09:49] | danielk22: | stuartm: stuarta: I think we should do that, maybe with a #define for anyone that wants to experiment with the resolution algorithm. |
| [22:12:40] | stuartm: | ok, I can write up a patch and we can tweak the details before committing |
| [22:13:55] | jams: | haha stuartm..i read that as "break the details" |
| [22:23:02] | j-rod is now known as j-rod|afk | |
| [22:39:22] | brfransen (brfransen!~brfransen@adrianDHCP-47.216-254-250.iw.net) has quit (Read error: Connection reset by peer) | |
| [22:39:53] | brfransen (brfransen!~brfransen@adrianDHCP-47.216-254-250.iw.net) has joined #mythtv | |
| [22:47:30] | Steve_Goodey (Steve_Goodey!~steve@host86-147-81-4.range86-147.btcentralplus.com) has joined #mythtv | |
| [23:05:26] | Steve_Goodey (Steve_Goodey!~steve@host86-147-81-4.range86-147.btcentralplus.com) has quit (Ping timeout: 240 seconds) | |
| [23:17:00] | stuarta: | stuartm: i had been contemplating ways of allowing EIT data to be used for non-EIT sources |
| [23:17:08] | stuarta: | it's a long outstanding issue |
| [23:17:32] | stuarta: | one thing that had come to mind is using the xmltvid to join the dots |
| [23:18:14] | stuarta: | ah, i just thought of one possible issue |
| [23:18:39] | XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [23:19:44] | stuarta: | we don't record the source of the program data, so there's no way of telling if the data came from xmltv or EIT, thus the backfilling of broken xmltv feed would stop and start as the EIT data was added to the channel |
| [23:21:36] | MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 248 seconds) | |
| [23:25:17] | stuartm: | stuarta: I was thinking of starting simple, no guide data at all for the channel or below a certain threshold (1 to 3 days) then start inserting EIT events – that's not as clever as it should ultimately be and maybe there's will to make it more intelligent from the outset |
| [23:25:47] | stuartm: | add a guide data source enum to the program table for example |
| [23:27:59] | stuartm: | it's a trade-off between implementing something quickly to address an immediate problem vs the desire to have a really clever system that is almost seamless |
| [23:31:48] | stuartm: | right now the issue is that EIT has to be manually disabled on channels for which we have an xmltvid or bad things happen, but the presence of an xmltvid does not mean that xmltv is presently inserting data for the channel, it might be a permanent problem (xmltv source no longer supports the channel) or short term (xmltv source was offline when the grabber ran) |
| [23:34:50] | stuartm: | so making things easier for the user we want to disable EIT collection if xmltv is being used on channel and we don't want EIT to fail if the user has stopped using xmltv but not cleaned up the xmltvids, in dealing with the latter we have the added benefit of EIT becoming a fallback should xmltv fail but it's not the reason for the making the change |
| [23:34:54] | abqjp (abqjp!~abqjp@97-119-168-204.albq.qwest.net) has quit (Quit: abqjp) | |
| [23:35:25] | stuartm: | unless someone wants to take a run at a more complicated, but much cooler solution |
| [23:38:04] | stuarta: | sorry just had to pop out for a moment |
| [23:38:07] | ** stuarta reads up ** | |
| [23:39:54] | stuarta: | something that just came to mind. |
| [23:40:34] | stuarta: | if the data source != EIT (ie. it's one of the xmltv grabbers) then disable EIT for channels with xmltvids as you suggested |
| [23:41:03] | ** stuarta ponders ** | |
| [23:41:46] | stuarta: | i'm trying to work out how to support what you want and the outstanding issue of not being able to feed EIT data to the same channel on other sources |
| [23:43:59] | stuarta: | is a MFDB run with a grabber going to overwrite any existing program data? |
| [23:44:40] | stuarta: | what i think would work is what you've suggested above |
| [23:45:00] | stuartm: | this arose from something Devin Heitmuller said, basically that it's a PITA to go through all the channels disabling EIT for those which use xmltv/scheduledirect and that many new users don't understand the necessity of this step so their guide data and schedules are messed up as a result |
| [23:45:24] | stuarta: | how about this |
| [23:45:41] | stuartm: | MFDB will compare existing program data against incoming data and overwrite if it doesn't match |
| [23:45:48] | stuarta: | ah good |
| [23:46:07] | stuarta: | so if MFDB restarts after a period of backfilled EIT data it'll put the xmltv data back |
| [23:46:13] | stuarta: | excellent |
| [23:46:15] | stuartm: | yes |
| [23:47:12] | stuarta: | so if ((xmltvid != '') && days_of_data() > LOW_DATA_THRESH) disable EIT |
| [23:47:27] | stuarta: | if ((xmltvid != '') && days_of_data() < LOW_DATA_THRESH) enable EIT |
| [23:47:40] | stuartm: | actually, more accurate answer is that it depends on the grabber, ultimately the grabber data will be inserted over the xmltv data but some grabbers conserve resources by only grabber the next two days of data, plus any days that are missing |
| [23:47:57] | stuartm: | stuarta: basically what I was thinking |
| [23:48:14] | stuarta: | yeah. 3 days sound good as a LOW_DATA_THRESH? |
| [23:48:18] | stuartm: | s/grabber/grabbing/ |
| [23:48:55] | stuarta: | we kinda need to keep track of if EIT is the primary data source |
| [23:49:04] | stuartm: | stuarta: it does to me, at least whilst we have a 'dumb' solution, every xmltv source should be able to provide at least that much |
| [23:49:26] | stuarta: | that's what i was thinking |
| [23:49:54] | stuarta: | for the EIT only data source, i'd like to be able to leverage xmltvid's to cross feed data. |
| [23:50:11] | stuartm: | the EIT fallback is a last ditch, try to ensure that we keep recording as much as possible rather than failing entirely |
| [23:50:17] | stuarta: | for those odd people that require it |
| [23:51:15] | stuarta: | yeah, happy with that idea, if it's an xmltv data source and we are running out of data using EIT even for channels with an xmltvid |
| [23:51:29] | stuarta: | start using |
| [23:52:37] | stuarta: | anyway, bed time. nn |
| [23:53:17] | stuartm: | night |
| [23:58:25] | Beirdo: | http://xkcd.com/844/ |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.
