:: #mythtv

Daily chat history

Current users (72):

aarcane_, aloril_, amessina, Anssi, Beirdo, brfransen, caelor, Captain_Murdoch, Chutt, clever, coling, Cougar, danielk221, dblain, dekarl, eharris, ElmerFudd, fetzerch, ghoti, Gibby, gregL, GreyFoxx_, Guest72035, jams_, jarle, jarryd, jheizer, joe____, johanbr, joki, jpharvey, jst, jwhite, kc, kurre2, kwmonroe, laga_, moparisthebest_, mrand, MythLogBot, natanojl, Nothing4You, nyloc, peper03, poptix, purserj, rhpot1991, robink, rsiebert, Seeker`, seld_, Sharky112065, skd5aner, sl1ce, SmallR2002, sphery, sraue, stuarta, stuartm, superm1, taylorr, tgm4883, Tobbe5178, toeb, tonsofpcs, tris, wagnerrp, wahrhaft, wolfgang1, XDS2010, xris, _charly_
Saturday, October 12th, 2013, 00:19 UTC
[00:19:40] tafypz (tafypz! has quit (Remote host closed the connection)
[00:20:03] telscuba (telscuba! has joined #mythtv
[00:20:55] tafypz (tafypz! has joined #mythtv
[00:32:48] cecil (cecil! has joined #mythtv
[00:32:52] cesman (cesman!~cesman@pdpc/supporter/professional/cesman) has quit (Ping timeout: 264 seconds)
[00:52:34] rsiebert_ (rsiebert_! has joined #mythtv
[00:55:02] rsiebert (rsiebert! has quit (Ping timeout: 240 seconds)
[01:03:14] cecil (cecil! has quit (Ping timeout: 264 seconds)
[01:03:37] skd5aner: jpabq: interesting – thanks for the info
[01:11:55] telscuba (telscuba! has quit (Quit: leaving)
[01:23:31] natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has quit (Ping timeout: 245 seconds)
[01:38:51] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[01:54:19] cecil (cecil! has joined #mythtv
[01:55:07] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!)
[02:00:37] _nyloc_ (_nyloc_! has joined #mythtv
[02:04:09] nyloc (nyloc! has quit (Ping timeout: 240 seconds)
[02:11:55] cecil (cecil! has quit (Ping timeout: 272 seconds)
[02:15:22] cecil (cecil! has joined #mythtv
[02:19:18] cecil (cecil! has quit (Read error: Operation timed out)
[02:19:43] cecil (cecil! has joined #mythtv
[02:20:24] cecil is now known as cesman
[02:20:39] cesman (cesman! has quit (Changing host)
[02:20:40] cesman (cesman!~cesman@pdpc/supporter/professional/cesman) has joined #mythtv
[02:40:57] knightr_ is now known as knightr
[02:45:15] peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Ping timeout: 248 seconds)
[02:46:14] peper03 (peper03!~peper03@mythtv/developer/peper03) has joined #mythtv
[02:59:07] nyloc (nyloc! has joined #mythtv
[03:00:53] joki (joki! has quit (Ping timeout: 248 seconds)
[03:02:41] _nyloc_ (_nyloc_! has quit (Ping timeout: 245 seconds)
[03:03:32] wagnerrp: stichnot... is no longer here
[03:04:04] wagnerrp: well in case you're reading the logs, the problem is that recorder IDs are only valid until the next time the user reconfigures their tuners
[03:05:00] wagnerrp: there's a perl script floating around that will grab the recorder IDs out of the logs for as far back as your logs go
[03:07:06] joki (joki! has joined #mythtv
[03:43:21] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 245 seconds)
[03:44:45] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv
[04:11:36] tstorm (tstorm! has joined #mythtv
[04:22:56] tafypz (tafypz! has quit (Remote host closed the connection)
[04:55:40] jya: looks like the git_buildbot script isn't working.. when I push I get in the log "remote: git_buildbot: ERROR: Could not connect to localhost:9989: Connection was refused by other side: 111: Connection refused."
[05:58:21] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya)
[06:18:13] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[06:26:34] tstorm (tstorm! has quit (Quit: tstorm)
[06:31:05] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya)
[06:50:35] _nyloc_ (_nyloc_! has joined #mythtv
[06:52:45] nyloc (nyloc! has quit (Ping timeout: 272 seconds)
[07:02:13] SteveGoodey (SteveGoodey! has joined #mythtv
[07:22:43] dekarl: we should "simply" look at the PCR PID for our A/V sync needs...
[07:39:20] earthworm (earthworm! has joined #mythtv
[07:49:53] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[07:55:15] doev (doev! has joined #mythtv
[08:04:37] Darkchaos (Darkchaos! has joined #mythtv
[08:14:21] earthworm (earthworm! has quit (Ping timeout: 245 seconds)
[08:17:05] stoffel (stoffel! has joined #mythtv
[08:17:52] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 264 seconds)
[08:24:13] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv
[08:29:16] clever: dekarl: but does the PMT list a PID for the PCR?
[08:30:00] clever: ah, now that i look closer at a recent PMT dump i was playing with, its hidden within the same pid as the video stream
[08:34:46] Steve-Goodey (Steve-Goodey! has joined #mythtv
[08:35:00] dekarl: clever: iirc thats the default
[08:35:51] dekarl: ahh, looking at reveals how it works
[08:36:21] dekarl: but it can be a separate pid
[08:37:01] clever: i was expecting it to be listed a bit differently, so i didnt notice that part of the output
[08:37:14] clever: this is what ive been working on lately
[08:37:36] clever: the PCR id was in an odd place, so i didnt notice it until now
[08:38:55] dekarl: see e.g. this bug report where the PCR PID on a separate PID is not being recorded
[08:40:49] clever: as long as you properly read the PMT and check the correct pid, it should work i think
[08:43:19] doev (doev! has quit (Quit: Verlassend)
[09:00:11] dekarl: we handle it here . . . .html#l00650 notice the AddWritingPID if the PID is not a stream of the PMT
[09:05:15] dekarl: wagnerrp: I have a setting DailyArtworkUpdates=1 on all hosts be and fe, is that on purpose? I would have expected that it runs on the master backend => hostname of NULL
[09:08:26] warped_ (warped_! has joined #mythtv
[09:21:26] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya)
[09:23:51] stoffel (stoffel! has quit (Ping timeout: 272 seconds)
[09:36:47] Darkchaos2 (Darkchaos2! has joined #mythtv
[09:37:28] Darkchaos (Darkchaos! has quit (Ping timeout: 240 seconds)
[09:50:31] stuartm: dekarl: I would guess not
[09:53:38] dekarl1 (dekarl1! has joined #mythtv
[09:55:39] dekarl (dekarl! has quit (Ping timeout: 248 seconds)
[10:03:15] Cougar (Cougar!~cougar@2a03:5880:104:10:f507:6056:e136:7760) has quit (Ping timeout: 260 seconds)
[10:11:30] warped_ (warped_! has quit (Quit: warped_)
[10:11:38] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[10:15:23] Cougar (Cougar!~cougar@2a03:5880:104:10:90a8:8467:9a0a:b8a7) has joined #mythtv
[10:32:57] Steve-Goodey (Steve-Goodey! has quit (Quit: Konversation terminated!)
[10:50:01] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya)
[10:52:48] stuartm: dekarl1: any idea what error code 13 is for tv_grab_uk_rt or any xmltv script (since I can't seem to see use of error codes except 1/0 in uk_rt)
[11:02:06] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 245 seconds)
[11:03:31] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv
[11:21:59] stuartm: superm1: mageia/mandriva have user-editable config files which are used by some init/sys scripts to allow users to edit run-time options like verbosity, they are generally simple KEY=VALUE stuff where you can substitute in your own values and most importantly they are not overwritten when you upgrade unlike the actual init scripts – is there any chance of getting something like that for mythtv on ubuntu?
[11:23:34] stuartm: somewhere we can define additional args to the backend which will persist between upgrades?
[11:24:14] SteveGoodey (SteveGoodey! has quit (Quit: Konversation terminated!)
[11:39:51] rsiebert_ (rsiebert_! has quit (Remote host closed the connection)
[11:44:01] rsiebert (rsiebert! has joined #mythtv
[12:07:21] dekarl1 is now known as dekarl
[12:08:11] earthworm (earthworm! has joined #mythtv
[12:13:06] earthworm (earthworm! has quit (Ping timeout: 245 seconds)
[12:17:40] natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has joined #mythtv
[12:22:59] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[12:29:14] stichnot: wagnerrp: seems like at a minimum, we could use cardinput.displayname as the tuner identifier in the recorded table.
[12:31:35] stichnot: With that said, I haven't reconfigured my tuners in years. Do others do that much more often?
[12:42:17] stuartm: I'm so used to finding the answers to pretty much any question I have through a search engine that when I can't find an answer anywhere it's strangely immensely frustrating – and yet I can remember a time when most curiosity driven questions you had went unanswered because we didn't have the internet
[12:43:41] stichnot: I remember sometimes having to go somewhere called a "library", where you might sometimes want to open a set of tomes called an "encyclopedia"
[12:45:43] stichnot: wagnerrp: When I do (did) reconfigure tuners, I'm accustomed to old recordings being shown with channel/callsign strings like "#2301/#2301".
[12:46:27] stuartm: stichnot: aye, I was even going to mention the encyclopedia (always had one on the shelf when I was a kid) – but even that never answered those funny little questions like – "I wondering what they are building on that site" or "What is that tool that all the police seem to be carrying on their belts these days?"
[12:48:37] stuartm: it's those sorts of questions that I've become so used to answering through a quick search – useless trivia but there was some satisfaction in answering my curiosity
[12:50:10] stuartm: todays question, was "WTF is with all those odd shaped door handles that I keep seeing all over the place, is it something to do with ergonomics or do they have some practical purpose?"
[12:50:53] stuartm: still no closer to an answer – seems _everyone_ sells them but no explanation for them :)
[12:52:39] stichnot: Now you've got me curious – picture?
[12:52:44] stuartm: no library or encyclopedia will help there, a trip to the hardware or door fitters might
[12:54:16] stuartm: stichnot: . . . g~~60_57.JPG
[12:54:54] stichnot: I often find that figuring out the official name is 90% of the battle. I spent years with an unsightly broken "air gap cover" for the dishwasher until I learned its name
[12:56:15] stuartm: on the left you've got a standard door handle, on the right the 'Pad' handle, now I did find that some manufacturers selling these sets (they are always one normal and one pad handle which goes on the outside) also use a special spindle that prevents the door being opened from the outside without the key
[12:56:26] stuartm: but that doesn't explain the shape of the handle
[12:57:42] stuartm: especially since you can use the 'split spindle' with a normal shaped handle
[12:59:03] stuartm: and let's face it, although I'm curious it's not worth jumping in the car or even making a phone call to get an answer
[13:00:11] doev (doev! has joined #mythtv
[13:05:39] stichnot: My guess is that it's just aesthetics. For whatever reason, you want the "attractive" pad handle on the outside and the "normal" lever on the inside. (You wouldn't install it the other way around because the screw heads go on the inside.)
[13:06:28] stichnot: Unless there's some UK-specific terminology going on here, this seems like a largely UK-only phenomenon.
[13:09:04] wagnerrp: dekarl: not sure about the setting, but the task only ever runs on the master backend
[13:09:12] wagnerrp: . . . ers.cpp#n631
[13:15:42] nyloc (nyloc! has joined #mythtv
[13:17:41] wagnerrp: . . . ngs.cpp#n253
[13:17:49] wagnerrp: seems that should be a SaveSettingOnHost()
[13:18:12] _nyloc_ (_nyloc_! has quit (Ping timeout: 272 seconds)
[13:28:14] _nyloc_ (_nyloc_! has joined #mythtv
[13:29:50] _nyloc__ (_nyloc__! has joined #mythtv
[13:31:01] nyloc (nyloc! has quit (Ping timeout: 245 seconds)
[13:31:23] nyloc (nyloc! has joined #mythtv
[13:32:51] _nyloc_ (_nyloc_! has quit (Ping timeout: 252 seconds)
[13:34:06] _nyloc_ (_nyloc_! has joined #mythtv
[13:34:08] _nyloc__ (_nyloc__! has quit (Ping timeout: 240 seconds)
[13:35:48] nyloc (nyloc! has quit (Ping timeout: 240 seconds)
[13:36:49] MaverickTech (MaverickTech! has quit (Ping timeout: 240 seconds)
[13:54:30] nyloc (nyloc! has joined #mythtv
[13:55:36] _nyloc_ (_nyloc_! has quit (Ping timeout: 245 seconds)
[14:02:29] allesmueller__ (allesmueller__! has joined #mythtv
[14:06:19] allesmueller_ (allesmueller_! has quit (Ping timeout: 248 seconds)
[14:08:20] warped_ (warped_! has joined #mythtv
[14:09:04] warped_ (warped_! has quit (Client Quit)
[14:26:57] dekarl: wagnerrp: yes, it appears as if "mythgame.MetadataGrabber" and "DailyArtworkUpdates" should be saved by SaveSettingOnHost() as its done with "MovieGrabber" and "TelevisionGrabber"
[14:31:57] stuartm: stichnot: probably more Europe-wide, the trend in this part of the world is for standardised lock designs, particularly for the modern multi-point locking doors (single lock throws multiple bolts and hooks at several points around the door)
[14:32:18] dekarl: if I understand MythDB::SaveSettingOnHost() then it needs additional code, e.g. as part of a schema update, to switch from a host specific setting to a global one?
[14:34:34] stuartm: dekarl: correct
[14:44:35] nyloc (nyloc! has quit (Ping timeout: 272 seconds)
[14:45:01] nyloc (nyloc! has joined #mythtv
[15:01:01] OldEnK (OldEnK! has joined #mythtv
[15:02:12] OldEnK (OldEnK! has left #mythtv ()
[15:27:50] superm1: stuartm: we did have /etc/default/mythtv-backend for a while, but since the upstart job is so simple and changes so rarely, it's trivial now to merge diffs with it so we removed the file from /etc/default . . . kend.upstart
[15:28:35] superm1: . . . 2/comments/6
[15:39:54] gigem_: stichnot: Yeah I personally don't think adding inputid would hurt, but sphery and possibly others have always poo-pood it. Since he/they do most of the user support, I defer to them. In reality, when diagnosing recording problems, the logs are generally still available and that is where the critical information needed to resolve problems usually resides.
[15:49:47] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!)
[15:56:13] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv
[15:58:45] gigem_ is now known as gigem
[16:28:15] allesmueller__ (allesmueller__! has quit (Quit: Ex-Chat)
[16:32:15] stichnot: gigem, sphery: If I were to do this, I would add a cardinputname column to recorded, default to the empty string, set to cardinput.displayname for new recordings, and display the value only on the Program Details screen (i.e., not themable). Maybe display in the mythweb UI as well.
[16:41:56] SteveGoodey (SteveGoodey! has joined #mythtv
[17:08:21] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 272 seconds)
[17:08:56] Darkchaos2 (Darkchaos2! has quit (Ping timeout: 245 seconds)
[17:32:11] SteveGoodey (SteveGoodey! has quit (Quit: Konversation terminated!)
[17:33:41] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[17:48:52] tstorm (tstorm! has joined #mythtv
[17:55:02] warped (warped! has joined #mythtv
[17:58:10] tstorm (tstorm! has quit (Quit: tstorm)
[17:58:52] rsiebert (rsiebert! has quit (Ping timeout: 246 seconds)
[17:59:06] rsiebert (rsiebert! has joined #mythtv
[18:09:28] rsiebert (rsiebert! has quit (Ping timeout: 240 seconds)
[18:10:19] rsiebert (rsiebert! has joined #mythtv
[18:14:13] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 272 seconds)
[18:31:38] caelor (caelor! has joined #mythtv
[18:34:00] caelor: stuartm referring back to your OT earlier about door handles, from having our doors replaced a year or so ago, we were told the paddle gave "improved security", because it's only ever used on split spindle, and so opportunists know it's not even worth trying
[18:34:58] caelor: so somewhere between something similar to security through obscurity, and complete rubbish. But, anything that discourages the opportunist :)
[18:42:51] stuartm: caelor: heh, thanks for that :)
[18:43:40] caelor: no problem :) a more cynical view might be that it makes it foolproof which one you put externally (I guess the paddles only receive the mounting screws)
[18:44:14] stuartm: yeah, I can't see how people know that the door will be locked offers greater security over the door actually being locked
[18:45:14] caelor: it's also probably a psychological thing – a traditional handle on a split spindle would feel "wrong" when testing the door after locking
[18:45:28] caelor: (because you'd expect the handle to be rigid, rather than free)
[18:45:52] stuartm: occurred to me that perhaps the paddle handle shape makes it harder to lever for the cylinder shattering problems that were common a while ago (burglars discovered that if you applied enough pressure to the handle the lock would snap)
[18:46:31] caelor: that's also plausible. in reality, there's probably lots of little good reasons
[18:47:06] caelor: I can't see the "convention" argument being the original reason, given there was no convention to follow when they were first used
[18:49:25] stuartm: personally I'd avoid split spindle, the doors in this place have a habit of blowing shut if there's a window open to create a through-flow of air, would be a continual pain if I had to make sure I had the keys just to put out the bins etc
[18:50:28] caelor: you get into a habit of making sure you have a key with you, or have a "failsafe" door that doesn't have split spindle (e.g. a back door)
[18:51:07] caelor: it's really the modern upvc/composite door equivalent of a yale lock
[18:51:27] dekarl: stuartm: xmltv error codes are only passed from the master to the apprentice or so it appears. Need to find a master ;)
[18:51:54] caelor: the little plastic bit to hold the latch back tends to be useless, so most people engage the deadbolts with the door open to prevent it closing and locking them out
[18:53:25] stuartm: caelor: yeah makes sense, used to do something similar with the yale (night latch) back in the day to avoid the door slamming shut behind me
[18:53:57] stuartm: dekarl: hmm
[18:56:23] stuartm: I can infer that the error was something to do with 'failed to obtain data' or 'failed to write to temp file' since mfdb followed by complaining that no data was forthcoming ... but I'm still in the dark – basically it works when run manually, but when run automatically in the early hours of the morning it has been failing :/
[18:57:45] caelor: stuartm – not a solution, but came up in my googling for xmltv error codes
[18:58:34] caelor: which also refers to manual working and automated failing
[19:00:28] stuartm: caelor: thanks
[19:01:00] caelor: no problem. On a different note, are there any known fixed deadlocks since 0.27 was released (on 0.27, rather than master)?
[19:01:21] caelor: I read about the backend idle deadlock, but I think that might be the only one, am I right?
[19:01:48] stuartm: caelor: one, last night, but only affecting those using slave backends
[19:03:16] caelor: ok, shouldn't be hitting me then. Had to restart my backend last night because it appeared deadlocked (I grabbed a core with gcore, but didn't think to gdb bt it). Backend is again sitting at 100% cpu and seems deadlocked
[19:03:33] caelor: is a core or backtrace more useful?
[19:04:06] wagnerrp: can't do anything with a core unless you have all the binaries that generated it
[19:04:18] caelor: I'm still on a mythbuntu build from the day after 0.27 release
[19:04:27] caelor: ok, backtrace it is :)
[19:04:32] wagnerrp: ultimately, you can do more with a core
[19:04:40] wagnerrp: but we specifically can't do anything with a core
[19:05:19] caelor: actually, it's not deadlocked, just very slow to respond. Will grab a backtrace and head to -users
[19:13:56] stuartm: caelor: you can create a bt from a core so long as you still have the identical binaries that generated it, if you upgraded then the core is useless
[19:14:54] stuartm: but luckily you don't need to re-create the issue if you have the core
[19:15:12] caelor: stuartm – do you have a pointer for how, and I'll pull a bt out of the core I generated last night. Given this is more user support, I'm heading over to -users until it's a dev thing
[19:15:39] stuartm: gdb -c core.1234 --args mythbackend
[19:16:19] stuartm: then at the prompt, "set logging on", followed by "thread apply all bt full"
[19:23:48] natanojl: or simply gdb mythbackend core.1234
[19:26:31] stuartm: oooh fancy
[19:27:41] natanojl: :)
[19:28:51] natanojl: you'd need the rest of the commands of course
[19:29:18] caelor: indeed. Including "set pagination off", or a trigger happy spacebar
[19:42:18] dekarl: stuartm, I'll see if I can hunt down an old copy from before the mediawiki migration . . . p;oldid=1998
[19:44:12] dekarl: the working manual run is something like "sudo -u mythtvbackenduser mythfilldatabase"?
[19:45:58] dekarl: caelor, have you got the mythtv-dbg package installed?
[19:46:38] caelor: yes
[19:47:06] dekarl: good, helps with the backtraces
[19:51:46] caelor: so according to wagnerrp, (from last night) had several threads with mutex locks in the scheduler. Not sure if that's an issue. My current backend spinning seems to be in the SSDP thread, but I'm not seeing why at present
[19:53:13] caelor: I'll pull in the latest 0.27-fixes, and see if I still see it.
[19:55:34] Seeker` (Seeker`!~cjo20@unaffiliated/seeker) has quit (Remote host closed the connection)
[19:56:17] dekarl: wagnerrp, the top failures on are either with and on versions from the last month or really old versions that we don't support anymore
[19:56:59] warped (warped! has quit (Read error: No route to host)
[19:57:12] Seeker` (Seeker`!~cjo20@unaffiliated/seeker) has joined #mythtv
[19:57:28] warped (warped! has joined #mythtv
[20:03:20] caelor (caelor! has quit (Remote host closed the connection)
[20:03:55] stichnot (stichnot!~stichnot@ has joined #mythtv
[20:04:03] stichnot (stichnot!~stichnot@ has quit (Changing host)
[20:04:03] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[20:11:29] doev (doev! has quit (Quit: Verlassend)
[20:12:03] caelor (caelor! has joined #mythtv
[20:12:52] wagnerrp: dekarl: is there any way to see what these errors actually are?
[20:13:28] wagnerrp: the only two "bugs" i've fixed in the past few months with were inability to handle bad data being sent from the API server
[20:14:16] wagnerrp: oh, they're off to the far right, off the page
[20:14:40] wagnerrp: ... and i can't view them
[20:24:03] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 272 seconds)
[20:40:49] skd5aner: hmmmm, I remember reading about this a few months ago, but I'm wondering if there's any potential here for MythTV to work around some of the CCI flag stuff – probably not, but it would be nice:
[20:47:16] jpabq: skd5aner: How long are your problematic recordings? The one that I ran into is several hours long. If I chop it down to an hour, it plays fine. So, I think stichnot's idea of the seek-to-end that happens when playback starts, may be the problem I ran into.
[20:48:00] skd5aner: I think I've got a 30 min one laying around, a few hour ones, and a few 3+ hour ones
[20:48:31] skd5aner: although, I have plenty of all the above that playback fine as well
[20:48:45] jpabq: Weird
[20:50:02] skd5aner: the 2 or 3 that I used dd to chop down to the first 50MB all playback fine
[20:50:13] skd5aner: regardless of original size/length
[20:55:05] wagnerrp: skd5aner: chances are it would require DTCP
[20:55:23] wagnerrp: or whatever that UPNP DRM format is
[20:58:54] clever: i was trying to crack some upnp stuff this week, the crazy buggers claim url-formencoded post data, then send raw binary!
[20:59:39] clever: for example
[21:04:35] skd5aner: wagnerrp: drm shmee-r-m
[21:05:00] clever: what i find even more odd, the twonky app on ipad works, the twonky app on android doesnt
[21:05:12] clever: and the play store is filled with nothing but comments about how the latest update broke it
[21:05:37] skd5aner: if only it was easier to actually watch the content people pay for than it is to actually "steal" it... :/
[21:05:51] skd5aner: what a concept
[21:05:58] clever: the packet in my pastebin, is just to push youtube videos to the STB
[21:06:07] clever: which is unable to even rewind the videos
[21:07:05] clever: the actual protected content is all standard, multicast/rtp/mpegts/CA codes
[21:07:50] clever: they just went out of their way to cripple the stuff for watching videos of kittens:
[21:08:13] ** wagnerrp wonders if his satellite box is actually on... **
[21:09:23] skd5aner: wagnerrp: satellite now?
[21:09:30] skd5aner: wagnerrp: you just using hd-pvrs?
[21:11:20] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[21:11:22] wagnerrp: just one. still using antenna for most things
[21:11:56] skd5aner: went the sphery route eh?
[21:13:43] wagnerrp: "Your TV does not support this programs content protection. Replacing the TV's HDMI cable with component cables will allow you to view the program."
[21:13:51] wagnerrp: well that's.... odd
[21:14:08] wagnerrp: but at least it's somewhere
[21:20:32] skd5aner: wagnerrp: what provider?
[21:22:39] wagnerrp: directv
[21:23:17] skd5aner: you know you can control most of their modern STBs via IP... HTTP I believe
[21:25:02] skd5aner: . . . _via_Network
[21:25:34] skd5aner: actually – this is new (from the last time I looked)
[21:26:09] wagnerrp: i don't recall whether the primary unit is on the network or not
[21:26:14] nyloc (nyloc! has quit (Read error: Operation timed out)
[21:27:05] nyloc (nyloc! has joined #mythtv
[21:53:25] warped (warped! has quit (Quit: warped)
[23:03:03] rsiebert (rsiebert! has quit (Remote host closed the connection)
[23:09:57] rsiebert (rsiebert! has joined #mythtv

IRC Logs collected by BeirdoBot.
Please use the above link to report any bugs.