:: #mythtv

Daily chat history

Current users (76):

aarcane_, aloril_, amessina, Anssi, Beirdo, brfransen, caelor, Captain_Murdoch, Chutt, clever, coling, Cougar, danielk221, dblain, dekarl, eharris, ElmerFudd, fetzerch, ghoti, Gibby, gregL, GreyFoxx, Guest12541, jams_, jarle, jarryd, jheizer_, joe____, johanbr, joki, Jordack, jpharvey, jst, jwhite, jya, kc, kurre2, kwmonroe, laga_, moparisthebest, mrand, MythBuild, MythLogBot, nephyrin, Nothing4You, nyloc, peper03, poptix, purserj, rhpot1991, robink, rsiebert, Seeker`, seld_, Sharky112065, skd5aner, sl1ce, SmallR2002, sphery, sraue, stuarta, stuartm, superm1, TandyUK2, taylorr, tgm4883, Tobbe5178, toeb, tonsofpcs, tris, wagnerrp, wahrhaft, wolfgang1, XDS2010, xris, _charly_
Monday, October 14th, 2013, 00:02 UTC
[00:02:15] skd5aner: stichnot, gigem, wagnerrp: I think it was you guys who were discussing the merits of tracking the recorder in an easy to recover way so that you can see which recording was targetted for which input. I can tell you that I personally would love that feature
[00:03:37] skd5aner: Everytime a recording fails, the first question I always have is "which tuner failed" – it's not always easy to tell, and depending on the tuner (QAM vs Cablecard vs HD-PVR vs Analog) could determine several reasons for failure (QAM channels moved vs USB failure vs Cablecard/SDV issues, etc)
[00:04:05] skd5aner: and it's always a pain in the butt to find out which recorder was leveraged on the failed recording
[00:04:17] wagnerrp: there's been a script on the wiki for a couple years that gives you an input id for the past several recordings
[00:04:29] wagnerrp: my comment was just that those input ids can change
[00:04:39] skd5aner: In fact, I'm looking at 2 recordings that failed tonight and I would definitely not expect those recordings to have failed...
[00:04:42] wagnerrp: so using that specifically to track it is not ideal
[00:05:17] skd5aner: wagnerrp: yea, but oh well... channelIDs change during rescans too and I have several recordings that are years old that have "unmapped" channel IDs
[00:05:48] wagnerrp: right, and that causes problems with trying to cross reference information about the station
[00:05:55] skd5aner: actually, to me – that's a more annoying problem because any stat related items (like on mythweb) are thrown off when it comes to channels most recorded, etc
[00:07:05] skd5aner: for tuners, couldn't some kind of guid be assigned based on queried serial number or other unique data so that it could persisted somehow?
[00:07:33] wagnerrp: see stuartm's comment from earlier today
[00:07:36] skd5aner: something like a table that keeps any tuner/input ever added to the system for tracking purposes
[00:07:55] skd5aner: wagnerrp: ok :) (sorry – have not read backlog – just got in and saw some failed recordings as we speak)
[00:08:10] skd5aner: wagnerrp: do you have a link to that script you mentioned?
[00:08:17] wagnerrp: it's the discussion immediately preceding this one
[00:08:58] wagnerrp:
[00:09:08] wagnerrp: . . .
[00:09:28] wagnerrp: the perl one reads the log file, the python one reads the logs out of the database
[00:09:37] wagnerrp: i'm not actually sure if the perl one still works
[00:09:50] wagnerrp: and the python one, of course, requires you enable database logging
[00:11:03] skd5aner: I see the conversation now, hehe – sounds like stuartm and I were on the same wavelength...
[00:13:26] skd5aner: the perl one works, I just used it
[00:14:17] skd5aner: although, it outputs the raw capture card ID, video source ID and Channel ID... would be nice if it could display the alias name
[00:14:25] skd5aner: but, I'm assuming that's not in the logs (I haven't looked)
[00:16:13] skd5aner: hmmm, was my PCI tuner that failed -odd, maybe it finally crapped out after 8 years :)
[00:30:30] tonsofpcs: skd5aner: everytime a recording fails for me it's because the ATSC lacks PSIP and there's no way for me to set default PID mapping so it has to wait for tables every time it tunes...
[00:32:35] skd5aner: tonsofpcs: i've had recorders fail for any number of reasons, my HD-PVR has failed because of faulty USB on the mobo, a defective power supply, and also just randomly... I've had DVB/ATSC tuners that have failed because of a random driver issue (very rarely), and I've had my providers remap their QAM channels before
[00:32:49] skd5aner: so, for me... it's never a guarentee of a single reason for failure :)
[00:35:12] tonsofpcs: I'm just bringing this up because the past few times I've brought up opening a ticket for TVCT issues I've been pointed to a "duplicate" that has nothing to do with them because it has a passing reference to tables. CVCT issues could be resolved similarly as well.
[00:35:38] tonsofpcs: anyway, I think storing as much metadata as possible along side recordings sounds like a good idea.
[00:36:23] tonsofpcs: it's not like most users are recording less than 1 minute at less than 2Mbps, there's no way you're going to eat an unreasonable amount of storage by storing anything possibly related.
[00:37:14] tonsofpcs: heck, even if you capture tables and write them out, you're still eating a trivial amount of space.
[00:38:42] skd5aner: I find it pretty baffling, as a user, that I can't press the "info" button on a recording and see which tuner actually (tried to) record that recording
[00:38:51] skd5aner: seems like a no brainer to me :)
[00:39:08] tonsofpcs: right.
[00:39:11] skd5aner: or the extra info that's provided if you press I twice
[00:39:23] tonsofpcs: ETT or the like, yea
[00:39:44] tonsofpcs: I mean, even though I record based on SD data, it'd be cool if the EIT and ETT were stored as well
[00:40:51] tonsofpcs: that said, I personally don't even use the myth interface for playback, I just use DLNA clients. If the myth interface had more useful details, I might move to using it. (I might move to using it anyway when I move and redesign my watching environment but that's a few months out as well... I'm still running 0.25+fixes anyway)
[00:41:23] skd5aner: interesting... which DLNA clients are you using? I just don't think I could commit to that
[00:41:44] tonsofpcs: I use a Sony standalone player.
[00:41:46] skd5aner: although, now that I think about it – I wonder how my samsung TV does as a client... I don't even think I have it hooked to the network right now
[00:42:04] tonsofpcs: I also run minidlna on my myth box for files that I throw on it.
[00:42:29] tonsofpcs: and I'll sometimes use the android tablet(s) as clients [bubbleupnp]
[00:42:50] tonsofpcs: if I want to watch on my laptop, I copy the stream url from mythweb and load it in vlc
[00:45:24] tonsofpcs: I may just get a WD at the new place for the projector (right now I use a Samsung HD tuner for live viewing there and a Sony Bluray player that doesn't do DLNA – I don't watch recorded shows on the big screen)
[00:50:56] tonsofpcs: right now I need to find a contractor to tell me how much it will cost me once I sign on the buy line to see if I'm actually going to buy it and move in...
[00:51:10] tonsofpcs: but yes, store all the metadata!
[00:51:22] tonsofpcs: if there's a question, the answer is 'yes, that too'
[00:51:42] skd5aner: :)
[00:52:31] rsiebert_ (rsiebert_! has quit (Read error: Operation timed out)
[00:52:36] rsiebert (rsiebert! has joined #mythtv
[01:51:30] Guest43400 (Guest43400!dblain@mythtv/developer/dblain) has joined #mythtv
[01:53:28] dblain (dblain!dblain@mythtv/developer/dblain) has quit (Ping timeout: 256 seconds)
[02:02:48] skd5aner: stuartm, natanojl: seeing similiar symptoms as I was a few days ago tonight... (after upgrading). This time it looks like mysql was maxing out the cores most of the time on the MBE, but the symptoms on the frontend were the same...
[02:03:30] skd5aner: notificaiton window constantly saying that mythbackend is connected (maybe "mythcontext is connected"? don't remember exact verbiage) – and the list never loading for nearly 10 minutes...
[02:05:05] skd5aner: stuartm: here's the mbe logs –
[02:05:49] nyloc (nyloc! has joined #mythtv
[02:06:03] skd5aner: stuartm: and the backtrace –
[02:06:08] skd5aner: (from the mbe)
[02:08:57] Guest43400 is now known as dblain
[02:10:25] _nyloc_ (_nyloc_! has quit (Ping timeout: 272 seconds)
[02:32:26] _nyloc_ (_nyloc_! has joined #mythtv
[02:34:08] nyloc (nyloc! has quit (Ping timeout: 240 seconds)
[02:42:48] peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Ping timeout: 240 seconds)
[02:43:51] peper03 (peper03!~peper03@mythtv/developer/peper03) has joined #mythtv
[02:53:55] skd5aner: argh! it's doing it again now stuartm... 2 cores at 100% for mythbackend, 2 cores at 100% for mysql
[03:03:13] clever: skd5aner: does 'show processlist' say anything in mysql?
[03:03:22] joki (joki! has quit (Ping timeout: 246 seconds)
[03:04:24] skd5aner: clever: I just killed everything off... I'll have to remember that for next time, which at this rate, is about every other day :) :(
[03:08:48] joki (joki! has joined #mythtv
[03:18:57] dblain (dblain!dblain@mythtv/developer/dblain) has quit (Read error: Connection reset by peer)
[03:19:07] dblain (dblain!dblain@mythtv/developer/dblain) has joined #mythtv
[03:52:06] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 245 seconds)
[03:53:24] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv
[05:12:27] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 272 seconds)
[05:41:57] _nyloc_ (_nyloc_! has quit (Ping timeout: 272 seconds)
[05:44:36] nyloc (nyloc! has joined #mythtv
[05:53:14] nyloc (nyloc! has quit (Read error: Operation timed out)
[05:55:17] nyloc (nyloc! has joined #mythtv
[05:57:28] nyloc (nyloc! has quit (Read error: Operation timed out)
[05:59:07] nyloc (nyloc! has joined #mythtv
[06:01:58] SteveGoodey (SteveGoodey! has joined #mythtv
[06:02:41] _nyloc_ (_nyloc_! has joined #mythtv
[06:03:56] nyloc (nyloc! has quit (Ping timeout: 256 seconds)
[06:07:28] _nyloc_ (_nyloc_! has quit (Ping timeout: 246 seconds)
[06:09:15] FabriceMG (FabriceMG!~Thunderbi@ has joined #mythtv
[06:10:21] nyloc (nyloc! has joined #mythtv
[06:12:25] SteveGoodey (SteveGoodey! has quit (Quit: Konversation terminated!)
[06:32:50] eharris (eharris! has quit (Ping timeout: 256 seconds)
[06:34:41] eharris (eharris! has joined #mythtv
[06:39:34] aarcane (aarcane! has joined #mythtv
[06:39:51] jarle (jarle! has quit (Quit: Leaving)
[06:41:09] jarle (jarle! has joined #mythtv
[06:41:41] aarcane_ (aarcane_! has quit (Ping timeout: 245 seconds)
[06:42:00] jarle (jarle! has quit (Remote host closed the connection)
[06:49:07] eharris (eharris! has quit (Ping timeout: 246 seconds)
[06:51:01] eharris (eharris! has joined #mythtv
[06:54:32] FabriceMG (FabriceMG!~Thunderbi@ has quit (Quit: FabriceMG)
[06:54:59] FabriceMG (FabriceMG!~Thunderbi@ has joined #mythtv
[06:57:16] jarle (jarle! has joined #mythtv
[06:57:17] aarcane_ (aarcane_! has joined #mythtv
[06:57:34] aarcane (aarcane! has quit (Read error: Connection reset by peer)
[07:02:30] warped_ (warped_! has joined #mythtv
[07:03:23] warped_ (warped_! has quit (Client Quit)
[07:06:00] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[07:16:53] dekarl1: tonsofpcs: wrt the PID mapping, are the PMT/TVCT/CVCT missing for a longer time or are they just broadcast with insanely low repetions rates and we fail to see them fast enough before timing out?
[07:17:00] dekarl1 is now known as dekarl
[08:04:12] stuarta: stuartm: lemme have a look
[08:05:45] MythBuild (MythBuild! has joined #mythtv
[08:16:09] Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:359e:7f60:f7aa:eeca) has joined #mythtv
[09:53:26] dekarl1 (dekarl1! has joined #mythtv
[09:53:51] dekarl (dekarl! has quit (Read error: Operation timed out)
[10:22:24] warped_ (warped_! has joined #mythtv
[11:09:24] TandyUK2 (TandyUK2! has joined #mythtv
[11:19:50] stuartm: skd5aner: do you have any sort of restart script for mythbackend?
[11:20:50] stuartm: skd5aner: to rule out the obvious cause, is there plenty of free disk space for mysql?
[11:23:24] stuartm: stuarta: thanks
[11:27:57] Nothing4You (Nothing4You! has quit (Quit: Gone...)
[11:30:03] Nothing4You (Nothing4You! has joined #mythtv
[11:52:08] tonsofpcs: dekarl1: the last time it happened, about 38 hours.
[11:52:52] tonsofpcs: (TVCT are generally generated by a COTS PC. They crash and need to be rebooted and software brought back up. Some statons are slow to notice/care)
[11:57:56] TandyUK2: anyone know whether the BlackGold series of tuners works with ubuntu and mythtv?
[11:58:25] TandyUK2: considering buying a pair or BGT3600 Dual DVB-T2/DVB-C, Dual DVB-S2 if they are compatible
[11:59:07] stuarta: TandyUK2: #mythtv-users please
[12:00:57] TandyUK2: i tried that last time, 5 days and nobody answered one way or the other
[12:01:43] stuarta: the answer in this channel is if the os supports it, we support it
[12:02:08] stuarta: i suggest trying
[12:02:24] stuarta: that is where you find out about the hardware support
[12:04:28] TandyUK2: myth uses v4l right?
[12:36:52] stuartm: v4l, ivtv and a number of other APIs, but v4l-dvb is the relevant one here
[12:44:06] dekarl-work (dekarl-work!51c8c614@gateway/web/freenode/ip. has joined #mythtv
[12:46:29] dekarl-work: tonsofpcs: doh, thats long. how do STB handle that? As a relatively simple solution we could cache the multiplex and program_number and skip the TVCT by looking directly at the PAT/PMT, but I guess they are missing too if that happens?
[12:53:32] dekarl-work: maybe we could simply cache a list of all related pids for each service and generate a fake PAT/PMT with the firewire code if we don't see the PSIP for x time
[12:54:16] dekarl-work: or cache the last known good psip and use that to kickstart the recorder giving a speed up in the general case, too
[12:54:39] dekarl-work: but the last two options are more work then the first one ;)
[13:08:31] TandyUK2: dekarl-work: i like the second option in general tbh :P
[13:09:05] dekarl-work: the simple PID cache?
[13:09:19] TandyUK2: sorry third option
[13:09:24] dekarl-work: ;)
[13:09:26] Guest43400 (Guest43400!dblain@mythtv/developer/dblain) has joined #mythtv
[13:09:28] TandyUK2: keep a cahe of the last known good pid
[13:09:50] TandyUK2: imho that would have ramifications for more than just the current issue ;)
[13:10:11] TandyUK2: like when someone uses a slow satelite tuner to browse live tv
[13:10:42] TandyUK2: its hard breaking customers habits lol
[13:11:01] warped__ (warped__! has joined #mythtv
[13:11:55] TandyUK2: one of mine cant get his head round why things are missing when he uses live tv (after it locks using DVB-T, then other stuff starts recording, and the DVB-S only channels are 'missing')
[13:12:24] dblain (dblain!dblain@mythtv/developer/dblain) has quit (Read error: Connection reset by peer)
[13:12:25] warped_ (warped_! has quit (Read error: Connection reset by peer)
[13:12:25] superm1 (superm1!uid4318@ubuntu/member/superm1) has quit (Ping timeout: 246 seconds)
[14:04:54] superm1 (superm1!uid4318@ubuntu/member/superm1) has joined #mythtv
[14:21:35] Jordack (Jordack! has joined #mythtv
[14:37:39] dekarl-work (dekarl-work!51c8c614@gateway/web/freenode/ip. has quit (Quit: Page closed)
[14:47:29] gigem (gigem!~david@mythtv/developer/gigem) has quit (Quit: WeeChat 0.4.1)
[14:48:33] gigem (gigem!~david@mythtv/developer/gigem) has joined #mythtv
[15:03:59] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 272 seconds)
[15:05:40] FabriceMG (FabriceMG!~Thunderbi@ has quit (Quit: FabriceMG)
[15:47:46] wuddigel (wuddigel! has joined #mythtv
[15:47:52] skd5aner: stuartm: yea, plenty of space on the disk where the DB is. And I use upstart for mythbackend, if that's what you're asking???
[15:48:40] skd5aner: stuartm: did that backtrace look similiar to that last one?
[15:50:26] stuartm: skd5aner: identical
[15:50:41] skd5aner: stuartm: well, that's "good" :)
[15:50:42] stuartm: gigem: ^^ scheduler deadlock
[15:50:55] skd5aner: I honestly was worrried it was a different issue
[15:51:03] skd5aner: same symptoms, different cause
[15:51:18] skd5aner: glad to hear, in a twisted way, it's still the same broken thing :)
[15:51:43] skd5aner: might I ask what your question about the backend restart script was referring to? Something that would automatically restart the backend if it became deadlocked?
[15:53:19] skd5aner: gigem: probably won't help since it's me... I've lobbed too many scheduler grenades over the fence at him ;-)
[15:53:22] skd5aner: heh
[15:54:01] skd5aner: remove the ":"
[15:54:24] stuartm: skd5aner: the logs from the slave might be useful, it's deadlocking while trying to get a response from the slave
[15:58:20] skd5aner: stuartm: k, I'll see if I can dig them up
[16:04:26] Guest43400 is now known as dblain
[16:05:36] stichnot (stichnot!~stichnot@ has joined #mythtv
[16:05:37] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[16:05:37] stichnot (stichnot!~stichnot@ has quit (Changing host)
[16:08:10] stuartm: gigem: the problem is actually in the socket code/usage somewhere :/
[16:17:10] superm1: assuming skd5aner is using the upstart script that's part of deb packaging (or something based on it), it should have something that will restart the backend if it crashes included
[16:17:22] superm1: but that shouldn't restart if it's a deadlock
[16:24:47] stuartm: skd5aner: wired or wireless? seems to keep losing connectivity according to the log – the main problem may be in our handling of unexpected disconnects, but I'm wondering why it so often drops the socket as well
[16:25:33] warped__ (warped__! has quit (Quit: warped__)
[16:25:37] stuartm: superm1: I once saw a similar problem when a restart script went wrong and started more than one instance of the backend, hence the question
[16:34:33] superm1: stuartm: yeah there was something wrong with how it was tracking forks
[16:34:43] superm1: it should be fixed now as long as skd5aner is using a current version
[16:35:12] superm1: . . . 18f38799c9fe
[16:39:16] natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has joined #mythtv
[16:40:18] stichnot (stichnot!~stichnot@ has joined #mythtv
[16:40:18] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[16:40:18] stichnot (stichnot!~stichnot@ has quit (Changing host)
[17:04:30] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[17:07:12] rsiebert (rsiebert! has quit (Remote host closed the connection)
[17:09:29] Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:359e:7f60:f7aa:eeca) has quit (Quit: Leaving)
[17:10:39] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 272 seconds)
[17:11:31] rsiebert (rsiebert! has joined #mythtv
[17:11:53] warped_ (warped_! has joined #mythtv
[17:13:47] warped_ (warped_! has quit (Client Quit)
[17:15:13] skd5aner: stuartm: wired – 1gigE. I don't think I'm having any flopping on the connectivity
[17:15:18] SteveGoodey (SteveGoodey! has joined #mythtv
[17:16:59] skd5aner: superm1: I do not use mythbuntu, I compile from scratch on ubuntu vanilla server... but I do use some of your scripts, let me check out that commit
[17:21:44] skd5aner: superm1: yea, mine is a bit different – I've had the current script for a few years
[17:22:35] skd5aner: er, no... hang on – looked at hte wrong thing
[17:29:20] skd5aner: superm1: yup, I'll use the latest version of your upstart scripts – but I'm assuming that's not really going to make much of an impact on this problem I'm seeing
[17:31:36] SteveGoodey (SteveGoodey! has quit (Quit: Konversation terminated!)
[17:34:37] SteveGoodey (SteveGoodey! has joined #mythtv
[17:37:01] moparisthebest_ (moparisthebest_! has quit (Read error: Connection reset by peer)
[17:39:47] moparisthebest (moparisthebest! has joined #mythtv
[17:42:39] skd5aner: stuartm (and gigem): here's the slave be logs from the same timeframe –
[17:43:48] stuartm: danielk221: I'm a little stumped on this issue see by skd5aner, I've been looking at the slave socket handling generally in light of the other bugs seen and it seems that the slave only opens a single connection which functions as both a command and event socket, so I'm wondering why that's considered OK for a slave connecting to the master, but not a frontend?
[17:44:25] skd5aner: stuartm: I always find the "fun" stuff, don't I? :D
[17:46:03] stuartm: danielk221: I had to make a change that disabled the callbacks whenever PlaybackSock::SendReceiveStringList() was used because this caused havoc with slave comms, sometimes our replies would be swallowed by the callbacks and ReadStringList() would be waiting for nothing
[17:46:47] stuartm: but I'm now thinking that if the callback is disabled at the moment we lose the connection, then MainServer won't know of the disconnect and attempt reconnection
[17:48:01] stuartm: if it wasn't such a can of worms I'd implement the same dual-socket setup for slaves as is used elsewhere
[17:48:37] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[17:49:28] stuartm: hmm – there I go jumping the gun again, I'm only disabling the ReadReady callback so the disconnect callback should still be received
[17:50:35] wuddigel (wuddigel! has left #mythtv ()
[17:50:43] rsiebert (rsiebert! has quit (Ping timeout: 260 seconds)
[17:54:14] tonsofpcs: dekarl1: in my experience, STBs either cache the channel numbers and get the right PIDs (not sure if they cache all PIDs or just PMT reference) or look up by PMT just as they would on a channel that never had TVCT.
[17:54:22] stuartm: danielk221: the slave using the one the socket is the reason for the 'hack' in PlaybackSock::SendReceiveStringList() to handle BACKEND_MESSAGE which are received while we're waiting for a reply
[17:54:23] skd5aner: fyi, I just updted my upstart scripts to the equivalent of what superm1 posted
[17:54:42] rsiebert (rsiebert! has joined #mythtv
[17:54:48] tonsofpcs: I'm sure there's also some STBs that will fail to tune too.
[17:55:08] skd5aner: I have to step away for a bit, I'll check back in later
[17:55:09] skd5aner: thanks
[17:57:42] warped_ (warped_! has joined #mythtv
[18:00:18] stuartm: skd5aner: can you start running the backend with -v network?
[18:00:41] rsiebert (rsiebert! has quit (Ping timeout: 272 seconds)
[18:01:13] stuartm: -v network,socket might get us there quicker, but it's easy to lose the information data in the noise that excessively verbose logging creates
[18:02:06] rsiebert (rsiebert! has joined #mythtv
[18:10:02] tonsofpcs (tonsofpcs! has quit (Changing host)
[18:10:02] tonsofpcs (tonsofpcs!~tonsofpcs@rivendell/member/tonsofpcs) has joined #mythtv
[18:29:27] dekarl1 is now known as dekarl
[18:54:13] gigem: skd5aner, stuartm: I started to look at potential deadlocks in HandleIdleShutdown() a week or two ago when someone said the real problem had been fixed. It could have been stuartm wrt the socket issues. It sounds like the problem is still a socket issue. If that's the case, I'd prefer to not do anything with HandleIdleShutdown() until I can move all of the potentially blocking actions out of the current
[18:54:15] gigem: scheduler loop.
[19:00:34] stuartm: atm it seems that every slave socket issue we fix just reveals a new one
[19:01:31] gigem: Don't you love a good game of Whack-a-bug!
[19:02:13] stuartm: my moving the shutdown stuff out of the scheduler might avoid the complete deadlock scenario but it won't fix the underlying issue in the sockets
[19:03:41] stuartm: retracing a little, it strikes me as odd that we have to ask the slave whether it's tuners are busy – shouldn't the master know that already?
[19:03:42] gigem: I know.
[19:04:38] rsiebert (rsiebert! has quit (Ping timeout: 240 seconds)
[19:05:35] gigem: One of my intentions is for the scheduler to keep closer track of what the recorders are doing so such queries aren't needed.
[19:19:06] rsiebert (rsiebert! has joined #mythtv
[19:21:34] stuarta: gigem: should that be the scheduler, or a different thing, that keeps track of stuff like, connected backends, connected frontends, their status, and in an easily queryable fashion?
[19:29:39] rsiebert (rsiebert! has quit (Ping timeout: 260 seconds)
[19:31:04] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[19:35:04] stuartm: conceptually it would be nicer to have a BackendContext type class, which then allows other parts of the code to query that without needing to touch the scheduler or worry about scheduler locks
[19:37:24] stuartm: it would have it's own set of locks of course, but ideally more sophisticated ReadWrite Locks instead of Mutex locks
[19:42:59] stuartm: none of which fixes the immediate issues, it's just another case of getting sidetracked by "wouldn't it be nice if ..." :(
[19:47:43] rsiebert (rsiebert! has joined #mythtv
[20:08:33] stichnot: danielk221: You probably know the most here about cc608 stuff. I've been looking into #11899 and I don't understand the purpose of "field number" in the VBI CEA-608, particularly the SCTE-20 encoding. The MythTV code seems to want to split fields 1 and 2 into separate caption streams. Ffmpeg filters out anything in field 3 (which has to do with "film mode" and 3:2 pulldown). Ccextractor...
[20:08:33] ** MythLogBot **
[20:08:34] stichnot: ...pretty much ignores the field number and (apparently correctly) merges it all into a single caption stream. The ffmpeg code in mpeg12.c that filters out everything except field_no==1 and field_no==2 appears to be derived from a MythTV patch from #9829.
[20:08:34] ** MythLogBot **
[20:08:39] stichnot: Even with these fixes (combine everything from fields 1, 2, and 3 into a single caption stream), MythTV still has a bit of corruption – an extraneous character pair "XE" is occasionally inserted, and some text occasionally goes missing.
[20:08:45] stichnot: I'm hoping this is related to why CEA-608 captions on DVDs often display so badly under MythTV.
[20:09:46] stichnot: I've been trying to make sense of the spec document .
[20:17:57] gigem: stuarta: I've really only thought of it from a scheduler point of view. At first glance, stuartm's BackendContext sounds like a better idea.
[20:19:18] stuarta: yeah, we are talking about the same sort of thing, somebody recently was wondering about "sending messages to all connected frontends" and "knowing which ones are connected"
[20:19:26] stuarta: lots of stuff that can be done with that
[20:21:48] stuartm: well we already know which frontends are connected to the backend, and do send them messages constantly (schedule changes, record list changes, program info changes etc etc)
[20:22:34] stuartm: but whether there's a simple GetConnectedFrontendList() method or not ... that would of course be something the 'BackendContext' class would offer if it existed
[20:28:16] rsiebert_ (rsiebert_! has joined #mythtv
[20:28:20] rsiebert (rsiebert! has quit (Ping timeout: 245 seconds)
[20:34:35] stuarta: stuartm: sounds like a "fag packet design". design approved ;-)
[20:36:57] warped_ (warped_! has quit (Quit: warped_)
[20:37:22] natanojl: stuartm: dekarl : I wrote a little MusicBrainz grabber if you're interested: It's not 100% compatible with since it's lacking the -M option, but that is easily fixed
[20:38:21] stuartm: natanojl: nice! definitely interested, although it may be a few days before I get around to doing anything with it
[20:38:29] dekarl: natanojl: a) cool, b) oh noes snakes on a pastebin ;)
[20:38:40] dekarl: skd5aner: -^
[20:39:34] stuartm: if you create a ticket I'm less likely to forget, and Paul may jump in thereby saving me time :)
[20:39:45] rsiebert_ (rsiebert_! has quit (Ping timeout: 272 seconds)
[20:40:05] dekarl: stuartm, I'm happy to give you antecedence as I don't dig python :/
[20:40:45] stuartm: I can follow it easily enough, but I'm not fluent
[20:42:08] stuartm: that particular script is so short and tidy that most people can probably get their head around it
[20:42:49] stuartm: probably helps that's it's using a pre-existing musicbrainz lib
[20:42:56] rsiebert (rsiebert! has joined #mythtv
[20:43:17] stuartm: natanojl: thanks again for that :)
[20:43:28] natanojl: dekarl: ;)
[20:44:09] natanojl: stuartm: you're welcome :)
[20:45:54] dekarl: wagnerrp: thanks and doh. I'm looking at the patch with paul's help as a result of that mail already
[21:03:30] SteveGoodey (SteveGoodey! has quit (Quit: Konversation terminated!)
[21:23:28] rsiebert (rsiebert! has quit (Remote host closed the connection)
[21:28:53] rsiebert (rsiebert! has joined #mythtv
[21:48:20] natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has quit (Ping timeout: 245 seconds)
[22:07:10] knightr (knightr!~Nicolas@mythtv/developer/knightr) has quit (Ping timeout: 246 seconds)
[22:32:13] jpabq (jpabq!~quassel@mythtv/developer/jpabq) has quit (Remote host closed the connection)
[22:38:12] skd5aner: stuartm: want me to run the master and slave with -v network, socket?
[22:42:01] jpabq (jpabq!~quassel@mythtv/developer/jpabq) has joined #mythtv
[22:50:39] skd5aner: natanojl: sweet!!
[23:20:47] robink (robink!~quassel@unaffilated/robink) has quit (Quit: - Chat comfortably. Anywhere.)
[23:25:12] knightr (knightr!~Nicolas@mythtv/developer/knightr) has joined #mythtv
[23:28:03] robink (robink!~quassel@unaffilated/robink) has joined #mythtv

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