| Tuesday, April 29th, 2014, 00:19 UTC | ||
| [00:19:39] | sl1ce (sl1ce!~johnathan@pool-100-0-124-62.bstnma.fios.verizon.net) has joined #mythtv | |
| [00:22:06] | sl1ce (sl1ce!~johnathan@pool-100-0-124-62.bstnma.fios.verizon.net) has quit (Remote host closed the connection) | |
| [00:23:40] | sl1ce (sl1ce!~johnathan@pool-100-0-124-62.bstnma.fios.verizon.net) has joined #mythtv | |
| [00:27:36] | sl1ce (sl1ce!~johnathan@pool-100-0-124-62.bstnma.fios.verizon.net) has quit (Remote host closed the connection) | |
| [00:29:01] | sl1ce (sl1ce!~johnathan@pool-100-0-124-62.bstnma.fios.verizon.net) has joined #mythtv | |
| [00:33:42] | sl1ce (sl1ce!~johnathan@pool-100-0-124-62.bstnma.fios.verizon.net) has quit (Remote host closed the connection) | |
| [00:35:12] | sl1ce (sl1ce!~johnathan@pool-100-0-124-62.bstnma.fios.verizon.net) has joined #mythtv | |
| [00:44:20] | sl1ce (sl1ce!~johnathan@pool-100-0-124-62.bstnma.fios.verizon.net) has quit (Quit: Konversation terminated!) | |
| [00:52:01] | sl1ce (sl1ce!~johnathan@pool-100-0-124-62.bstnma.fios.verizon.net) has joined #mythtv | |
| [01:03:36] | andreaz (andreaz!~andre_000@p5DD14D8D.dip0.t-ipconnect.de) has quit (Read error: Connection reset by peer) | |
| [01:03:50] | taylorr: | skd5aner: skipping and rew/ffwd shouldn't be painful for HD-PVR H.264 recordings with a seektable.... has it gotten worse since 0.25? |
| [01:04:17] | skd5aner: | taylorr: skipping backwards is bad |
| [01:04:37] | skd5aner: | running 0.27-fixes from a month or so ago |
| [01:05:33] | skd5aner: | I usually don't rew/ffwd. I usually just skip or jump |
| [01:05:46] | skd5aner: | jump is ok in either direction. skip forward is ok |
| [01:05:51] | skd5aner: | skip back, can take seconds |
| [01:05:57] | skd5aner: | ... to respond |
| [01:14:15] | taylorr: | skd5aner: never noticed slow seek backwards with 0.25-fixes... shouldn't really matter if going back or forth with a seek table unless there is an issue with the ringbuffer |
| [01:15:28] | skd5aner: | I get instant reponse if I skip forward 30 seconds, but if I skip back 5 seconds, it sometimes takes a few seconds for it to respond and actually skip |
| [01:15:49] | skd5aner: | especially if I try to hit it more than one time, it seems to increment the response time |
| [01:18:56] | taylorr: | a forward or backwards seek using a seek table literally just reads the byte position from the seek table and sets the file position being read to it... nothing is done by ffmpeg at all |
| [01:19:42] | taylorr: | did this happen at some point during the -fixes branch or has it been a problem since the 0.27 release? |
| [01:22:38] | _nyloc_ (_nyloc_!~quassel@p3EE2D0CD.dip0.t-ipconnect.de) has quit (Ping timeout: 252 seconds) | |
| [01:25:31] | nyloc (nyloc!~quassel@p3EE2D4B3.dip0.t-ipconnect.de) has joined #mythtv | |
| [01:27:42] | skd5aner: | taylorr: it's been a problem for as long as I remember?? |
| [01:28:14] | skd5aner: | We've even discussed it around here in the last several months, I belive with jpabq and a few others |
| [01:29:48] | skd5aner: | and stichnot |
| [01:30:04] | skd5aner: | somewhere here: http://irc.mythtv.org/ircLog/channel/4/2014-01-12 and here: http://irc.mythtv.org/ircLog/channel/4/2014-01-13 |
| [01:30:37] | sl1ce (sl1ce!~johnathan@pool-100-0-124-62.bstnma.fios.verizon.net) has quit (Quit: Konversation terminated!) | |
| [01:33:58] | sl1ce (sl1ce!~johnathan@pool-100-0-124-62.bstnma.fios.verizon.net) has joined #mythtv | |
| [02:23:30] | jpabq: | skd5aner, taylorr, I patch my personal install with "const double MythPlayer::kInaccuracyDefault = 1.0" to avoid the painful seeking with the HD-PVR material. |
| [02:24:47] | jpabq: | default is 0.1 instead of 1.0 |
| [02:28:38] | jpharvey (jpharvey!~jpharvey@host86-179-38-232.range86-179.btcentralplus.com) has quit (Ping timeout: 240 seconds) | |
| [02:29:51] | peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Ping timeout: 276 seconds) | |
| [02:33:56] | _nyloc_ (_nyloc_!~quassel@p57B4F0FD.dip0.t-ipconnect.de) has joined #mythtv | |
| [02:34:23] | peper03 (peper03!~peper03@mythtv/developer/peper03) has joined #mythtv | |
| [02:38:22] | nyloc (nyloc!~quassel@p3EE2D4B3.dip0.t-ipconnect.de) has quit (Ping timeout: 265 seconds) | |
| [02:41:00] | jpharvey (jpharvey!~jpharvey@host109-148-236-62.range109-148.btcentralplus.com) has joined #mythtv | |
| [03:20:20] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 252 seconds) | |
| [03:21:25] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [04:59:38] | sl1ce (sl1ce!~johnathan@pool-100-0-124-62.bstnma.fios.verizon.net) has quit (Ping timeout: 240 seconds) | |
| [04:59:48] | sl1ce (sl1ce!~johnathan@pool-100-0-124-62.bstnma.fios.verizon.net) has joined #mythtv | |
| [05:37:12] | gregL (gregL!~greg@cpe-74-76-121-109.nycap.res.rr.com) has quit (Ping timeout: 265 seconds) | |
| [05:42:22] | jmusits (jmusits!~jmusits@cpe-69-205-28-169.nycap.res.rr.com) has quit (Ping timeout: 258 seconds) | |
| [05:42:53] | tonsofpcs (tonsofpcs!~mythbuntu@cpe-67-255-119-102.stny.res.rr.com) has quit (Ping timeout: 264 seconds) | |
| [05:44:38] | tonsofpcs (tonsofpcs!~mythbuntu@cpe-67-255-119-102.stny.res.rr.com) has joined #mythtv | |
| [05:45:23] | gregL (gregL!~greg@cpe-74-76-121-109.nycap.res.rr.com) has joined #mythtv | |
| [05:49:42] | jmusits (jmusits!~jmusits@cpe-69-205-28-169.nycap.res.rr.com) has joined #mythtv | |
| [05:54:36] | SteveGoodey (SteveGoodey!~steve@host217-42-221-3.range217-42.btcentralplus.com) has joined #mythtv | |
| [06:05:08] | nutron|h (nutron|h!~nutron@unaffiliated/nutron) has quit (Remote host closed the connection) | |
| [06:07:54] | SteveGoodey (SteveGoodey!~steve@host217-42-221-3.range217-42.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [06:08:54] | FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has joined #mythtv | |
| [06:27:12] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Ping timeout: 240 seconds) | |
| [06:27:33] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [06:34:22] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Read error: Connection reset by peer) | |
| [06:34:41] | fetzerch_ (fetzerch_!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [06:39:18] | fetzerch_ (fetzerch_!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 240 seconds) | |
| [06:42:27] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [07:31:38] | joki (joki!~joki@p548610BA.dip0.t-ipconnect.de) has quit (Ping timeout: 255 seconds) | |
| [07:33:03] | dekarl: | another nice frontend feature would be the ability to set chapter marks, e.g. at the beginning of each song of a concert recording, then export the chapters when running the lossless cut to matroska |
| [07:33:53] | dekarl: | ^- basically another "things to do to fresh tv recording" feature that is not present in the various "watch premade files" programs |
| [07:37:26] | joki (joki!~joki@p548611FA.dip0.t-ipconnect.de) has joined #mythtv | |
| [07:37:27] | dekarl: | jya, if its something in the database, could it be with the keyframe index? |
| [07:37:47] | jya: | i don’t know.. was that changed lately? |
| [07:37:53] | jya: | I’ve spent the day on this… |
| [07:37:59] | jya: | first I couldn’t reproduce it.. then I could |
| [07:38:09] | dekarl: | I don't remember recent changes |
| [07:38:26] | jya: | even using fixes/0.27 (using the master database, with config so the older code could use it |
| [07:38:42] | jya: | and once I restored a backup, it all worked again just fine... |
| [07:38:52] | dekarl: | but I have it "on the list" that we have 3 ways to generate the index and they don't agree on the data they generate... (that's what I remember from the discussion when I put it on "the list") |
| [07:39:21] | jya: | I thought at the beginning that this issue was related to a relatively recent issue when watching live TV and you change channels |
| [07:39:41] | dekarl: | was something with recorder vs. mythcommflag --rebuilt vs. mythtranscode --buildindex |
| [07:39:47] | jya: | sometimes it shows briefly (during the time it takes to change channels) and display a frame that could be several minute old |
| [07:40:47] | dekarl: | got to run, bbl |
| [07:41:35] | jya: | how are the connection managed by the backend ? trying to look into fixing this issue with RemoteFile where sometimes it will timeout after 16s and never reconnect |
| [07:41:57] | jya: | it seems to always coincide with a time where the scheduler is running or some databse work is going on |
| [07:43:16] | jya: | so I see multiple issues: if the backend if busy doing some mysql stuff. Either the machine becomes so slow that it can’t do anything else, or the handling of the remote request is queued waiting for the database stuff to be finished |
| [07:44:07] | jya: | looking at the code, the MainServer::ProcessRequest is handled is a QRunnable and is run in a different thread |
| [07:45:03] | jya: | however, could it be that the runnable is dependent on the main thread to process all requests ? |
| [07:45:06] | jya: | just asking…. |
| [07:45:08] | jya: | any ideas? |
| [07:45:31] | jya: | in any case, RemoteFile should be able to resume an interrupted connection |
| [07:45:56] | jya: | but if the backend can’t process requests in parallel, it’s a moot point |
| [07:51:27] | Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:4534:3f4:1086:b7d7) has joined #mythtv | |
| [08:09:50] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_) | |
| [08:50:30] | dekarl1 (dekarl1!~dekarl@p4FE8413A.dip0.t-ipconnect.de) has joined #mythtv | |
| [08:52:11] | dekarl (dekarl!~dekarl@p4FCEEF3C.dip0.t-ipconnect.de) has quit (Ping timeout: 252 seconds) | |
| [09:12:22] | rsiebert_ (rsiebert_!~quassel@e179185012.adsl.alicedsl.de) has quit (Ping timeout: 252 seconds) | |
| [09:17:01] | dekarl-work (dekarl-work!51c8c614@gateway/web/freenode/ip.81.200.198.20) has joined #mythtv | |
| [09:19:20] | dekarl-work: | fitting well to our talk about call sign databases for europeans... snouf from mythtv-fr asks about services.mythtv.org api to contribute icons https://forum.mythtv.org/viewtopic.php?f=33&t=142 |
| [09:54:34] | stuartm: | dekarl-work: saw that, am very busy atm but will reply to it later |
| [10:00:29] | stuartm: | stuarta: before I forget, some DVB-S2 channels are using a symbol rate of 23000, we only offer 22000 when scanning |
| [10:00:50] | stuarta: | oh.... shouldn't be a hard fix |
| [10:00:56] | stuarta: | think you can handle it? |
| [10:02:07] | stuartm: | sure |
| [10:18:28] | stuarta: | thanks |
| [10:26:36] | stuartm: | in fact I'm not sure what the correct approach is, a quick search suggests that unlike DVB-S/T S2 doesn't standardise the symbol rate at all, so any value is possible |
| [10:28:09] | stuartm: | if we're just going to build in the most commonly used then we should scrap that info from lyngsat or kingofsat somehow |
| [10:28:41] | stuarta: | i'd start with a list from the NIT/SDT |
| [10:45:03] | stuartm: | collision detection could use some work too, it shouldn't consider two channels with the same channum a problem unless their names are different |
| [10:45:21] | stuartm: | well, that should keep me busy tonight :) |
| [10:47:41] | stuarta: | stuartm: dekarl-work opened a ticket about that, we don't choose the "best" mux as per the specs |
| [10:48:26] | stuartm: | well in my situation it's two different sources |
| [10:49:25] | stuartm: | and two identical channels on different sources can/should share a single number to prevent them cluttering up the guide |
| [10:51:27] | rsiebert (rsiebert!~quassel@e179185012.adsl.alicedsl.de) has joined #mythtv | |
| [10:51:49] | stuarta: | oh that's been a long standing issue |
| [10:52:13] | jya: | hmmm… I see what the actual core issue is in RemoteFile… it;s actually in MythSocket::ReadReal(), it seems that if we don’t immediately read something within 10ms, it actually will fail as the error boolean is set |
| [10:54:42] | dekarl-work: | stuarta, stuartm. I understood the collision detection wrt channels as the issue that on DVB you can have multiple copies of (in theory) the same service_id within one original_network_id while the channel is being relocated. But, I know that there have been misconfigured networks out there with the same service_id for two unrelated channel on different transports of the same network... So "it's complicated" |
| [10:55:15] | stuarta: | it always is |
| [10:55:35] | dekarl-work: | if you receive the same transport via two video sources you'll get what appears as collision, too. but with different channum due to the video source id being part of the channum |
| [10:56:51] | stuartm: | dekarl-work: yeah, the same network and or/multiple transmitter issue is more complicated than the one I was going to fix |
| [10:57:32] | stuartm: | perhaps I shouldn't have used the term 'collision' since that just confused matters :) |
| [10:58:52] | stuartm: | dekarl-work: if you've bothered to carefully renumber the channels so that they all share the same channel number, then re-scans can get very messy and there's no reason it should be that way |
| [10:59:25] | jya: | I think what’s happening in the RemoteFile code, we request XX bytes, and start reading. We wait for XX bytes to be available for 10ms, after that it just read. If no data is available, it’s considered as attempting to read beyond the end of stream, which is an error. So the error boolean is set. As the backend as never been requested all the data, it never sends on the control socket how many bytes have been sent. As as such, the frontend timeout. |
| [10:59:26] | jya: | all goes downhill from there |
| [10:59:45] | jya: | that behaviour was introduced in the conversion to the new MythSocket code, right after 0.26 |
| [10:59:53] | dekarl-work: | stuartm, we could use some unit tests around these waters (hint LCN ;) |
| [11:01:09] | dekarl-work: | stuartm, also I agree wrt the channel scan messing around with manually adjusted data. Thats not so good. |
| [11:01:50] | dekarl-work: | On an unrelated note, now that we cache negative channel lookups in the eitscanner, should we just ignore the signalling of guide presence in the SDT. We've got multiple tickets about broadcasters messing it up |
| [11:02:40] | dekarl-work: | maybe even ignore it in the channel scan. But at least in the eit scan |
| [11:10:53] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [11:12:32] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Client Quit) | |
| [11:50:29] | Goga777 (Goga777!~Goga777@128-71-38-198.broadband.corbina.ru) has joined #mythtv | |
| [12:43:34] | rsiebert_ (rsiebert_!~quassel@g225011152.adsl.alicedsl.de) has joined #mythtv | |
| [12:46:51] | rsiebert (rsiebert!~quassel@e179185012.adsl.alicedsl.de) has quit (Ping timeout: 252 seconds) | |
| [12:49:24] | jheizer (jheizer!~jheizer@73.51.93.177) has joined #mythtv | |
| [12:54:25] | Goga777 (Goga777!~Goga777@128-71-38-198.broadband.corbina.ru) has quit (Remote host closed the connection) | |
| [13:30:45] | jya: | ohhhh.. playback can recover now even after restarting the backend |
| [13:32:00] | stuartm: | nice |
| [13:32:13] | jya: | must play pause before though |
| [13:32:33] | jya: | need to look into how to pause, rather than just exiting |
| [13:33:03] | jya: | it’s just a side effect of having RemoteFile attempting to reconnect when the socket is disconnected or errored |
| [13:40:09] | jya: | I really wonder why MythSocket::ReadStringList wil *always* just drop the tcp connection as soon as it timesout. Makes it almost impossible to handle a proper recovery… |
| [13:42:40] | jya: | so the only way to have a chance for everything to work properly and prevent drop out is to have extremely long timeout (and the default is 30s), which obviously prevent to do anything while waiting… Any there are plenty of connection to the backend in the GUI thread… (anything related to the playback status, recording etc…) |
| [13:42:56] | jya: | no wonder the frontend freezes for so long when the backend has a hiccup |
| [13:45:05] | stuartm: | jya: ReadStringList() dropping the connection is IMHO a flawed design, as I noted previously, it means we drop the connection even when the backend just don't have a response to send – we shouldn't be dropping the connection without first testing it with a simple heartbeat/"are you alive" quer |
| [13:45:29] | stuartm: | y |
| [13:45:36] | jya: | yes… indeed |
| [13:45:37] | stuartm: | off out |
| [13:46:37] | jya: | I’m afraid not dropping the connection however, may have dire consequences on any code relying for the connection to be dropped. There may not be any, but there are so many call to that function everywhere, and the code is usually so dirty… it’s a bit scary |
| [13:49:13] | dekarl-work: | Hmm, do we have the ressources to fix new bugs resulting from that change at the moment? Then I'd go for it. |
| [13:49:46] | jya: | there are so many bugs currently… and the one I’m attempting to fix is affecting 0.27 users |
| [13:49:51] | dekarl-work: | Similar to the isSameProgram changes. Slowly make stuff do the right thing |
| [13:50:02] | jya: | so I’m trying to minimise the impact so it can be backported |
| [13:50:25] | dekarl-work: | make sense |
| [13:50:39] | jya: | but yes… we could simple have in master a quick change that doesn’t close the connection when it times out |
| [13:50:52] | jya: | make much lower default timeout (e.g. 3s vs 30s) |
| [13:50:59] | jya: | and see how it goes... |
| [13:51:17] | jya: | I have the feeling it will work just fine |
| [13:51:36] | jya: | as far as resources go….. probably not |
| [13:52:08] | dekarl-work: | hmm. so just try it in master, and then decide to revert or keep it? |
| [13:56:28] | jya: | like here in RemoteFile, we request the backend for XXX bytes. Right after that we check if the control socket has some information about how much byte has been sent |
| [13:56:53] | jya: | really, who cares when you know how many bytes have been received? |
| [13:57:17] | jya: | but if I do attempt to read that value, got to wait up to 30s |
| [13:57:36] | jya: | and can’t make it wait a lesser time as then my connection is dropped… sigh |
| [13:58:29] | jya: | inside the ringbuffer it’s okay, because the readahead thread will call Read again 5 times, and now the code will re-establish the connection |
| [13:58:50] | jya: | but for other user of RemoteFile (like the utilities) it’s another issue |
| [13:59:28] | brfransen (brfransen!~brfransen@64.179.169.226) has quit (Ping timeout: 252 seconds) | |
| [14:00:21] | brfransen (brfransen!~brfransen@64.179.169.226) has joined #mythtv | |
| [14:22:27] | stuarta: | jya: i'd say fix it and see what happens if you don't kill the connection |
| [14:22:51] | jya: | it would require a much broader test base than just me. |
| [14:23:04] | jya: | I have a very good lan here |
| [14:34:19] | stuarta: | there is a tool which could prove very useful |
| [14:34:22] | stuarta: | lemme find it |
| [14:48:16] | jya: | when you play a video, you always stream from the masterbackend right? |
| [14:48:27] | jya: | or can you stream from a slave one too ? |
| [14:49:25] | stuarta: | i think that's what the masterbackendoverride setting is for |
| [14:51:39] | jya: | the help on masterbackendoverride is rather confusing |
| [14:51:50] | jya: | If enabled, the master backend will stream and" |
| [14:51:51] | jya: | " delete files if it finds them in a storage directory. " |
| [14:51:52] | jya: | "Useful if you are using a central storage location, like " |
| [14:51:53] | jya: | "a NFS share, and your slave backend isn't running |
| [14:52:07] | stuarta: | i don't find that confusing |
| [14:52:30] | jya: | that certainly doesn’t tell me that the frontend could actually stream from a slave backend :) |
| [14:52:51] | jya: | the reason I ask is that there’s a “IsConnectedToMaster” in corecontext |
| [14:53:11] | jya: | so when I reach an EOF, I check if I’m still connected to the backend |
| [14:53:23] | jya: | and if so I exit back to the main menu |
| [14:53:29] | jya: | otherwise I just do a pause instead |
| [14:53:39] | jya: | that way you can restart the backend while playback is going |
| [14:55:25] | gregL (gregL!~greg@cpe-74-76-121-109.nycap.res.rr.com) has quit (Read error: Connection reset by peer) | |
| [14:55:38] | dekarl-work: | I'd like to see mythutil --moverecording, so SBE can record to a small buffer (SSD, small disk, NFS) then move the file to the "master storage system" in a post-recording-hook. Then add an optimization to that move, if both storages are the same, just change the hostname and move on |
| [14:56:05] | dekarl-work: | step 2, add automatic shuffling of recordings to make auto-expire do what people expect |
| [14:56:28] | gregL (gregL!~greg@cpe-74-76-121-109.nycap.res.rr.com) has joined #mythtv | |
| [14:56:39] | jya: | sounds like a workaround for a problem that should be properly fixed :) |
| [14:56:45] | dekarl-work: | All this variants for <1% use cases add complexity for little gain |
| [14:59:52] | jya: | ok, pausing after reaching EOF can’t be resumed from it… but at least you can set a bookmark and quickly resume… |
| [15:10:12] | jya: | git server is down? |
| [15:10:23] | jya: | ah no… just responding again |
| [15:11:34] | dekarl-work (dekarl-work!51c8c614@gateway/web/freenode/ip.81.200.198.20) has quit (Quit: All work and no play makes Karl a dull boy.) | |
| [15:12:49] | jya: | super slow though |
| [15:29:01] | stuarta: | alcor? |
| [15:51:12] | FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has quit (Quit: FabriceMG) | |
| [16:04:12] | dekarl1 is now known as dekarl | |
| [16:11:27] | aloril (aloril!~aloril@dsl-tkubrasgw2-54f80b-12.dhcp.inet.fi) has quit (Ping timeout: 276 seconds) | |
| [16:24:30] | aloril (aloril!~aloril@dsl-tkubrasgw2-54f80b-12.dhcp.inet.fi) has joined #mythtv | |
| [16:32:34] | jpabq (jpabq!~quassel@mythtv/developer/jpabq) has quit (Remote host closed the connection) | |
| [16:41:02] | SteveGoodey (SteveGoodey!~steve@host217-42-221-3.range217-42.btcentralplus.com) has joined #mythtv | |
| [16:42:09] | jpabq (jpabq!~quassel@mythtv/developer/jpabq) has joined #mythtv | |
| [16:52:11] | gregL (gregL!~greg@cpe-74-76-121-109.nycap.res.rr.com) has quit (Remote host closed the connection) | |
| [17:05:10] | Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:4534:3f4:1086:b7d7) has quit (Quit: Leaving) | |
| [17:13:38] | Goga777 (Goga777!~Goga777@128-71-38-198.broadband.corbina.ru) has joined #mythtv | |
| [17:14:10] | brfransen (brfransen!~brfransen@64.179.169.226) has quit (Ping timeout: 265 seconds) | |
| [17:15:00] | brfransen (brfransen!~brfransen@64.179.169.226) has joined #mythtv | |
| [17:35:35] | Goga777 (Goga777!~Goga777@128-71-38-198.broadband.corbina.ru) has quit (Ping timeout: 240 seconds) | |
| [17:42:14] | gregL (gregL!~greg@cpe-74-76-121-109.nycap.res.rr.com) has joined #mythtv | |
| [17:48:14] | Goga777 (Goga777!~Goga777@128-71-43-164.broadband.corbina.ru) has joined #mythtv | |
| [17:57:30] | _nyloc_ (_nyloc_!~quassel@p57B4F0FD.dip0.t-ipconnect.de) has quit (Read error: Connection reset by peer) | |
| [18:04:46] | nyloc (nyloc!~quassel@p57B4F0FD.dip0.t-ipconnect.de) has joined #mythtv | |
| [18:32:24] | Goga777 (Goga777!~Goga777@128-71-43-164.broadband.corbina.ru) has quit (Read error: Connection reset by peer) | |
| [18:41:30] | andreaz (andreaz!~andre_000@p5DD14D8D.dip0.t-ipconnect.de) has joined #mythtv | |
| [18:41:57] | gigem: | stuarta: I've got recstatus being shown without false positives now, but I don't like it. The implementation, that is, not necessarily the intended result. Consequently, I need to work on it some more. I have come to the conclusion, though, that I'd much prefer any chicanery with recstatus be done in the scheduler, even if just on output. Unfortunately, that's not currently possible without more |
| [18:41:59] | gigem: | fundamental changes within the scheduler and I'm not yet ready to commit to any of them at the moment. |
| [19:45:14] | gregL (gregL!~greg@cpe-74-76-121-109.nycap.res.rr.com) has quit (Remote host closed the connection) | |
| [19:47:01] | gregL (gregL!~greg@cpe-74-76-121-109.nycap.res.rr.com) has joined #mythtv | |
| [19:49:59] | Jordack (Jordack!~Jordack@users.twp.ypsilanti.mi.us) has joined #mythtv | |
| [20:05:13] | bedo1979 (bedo1979!~mbe@mbe.qpsk.net) has joined #mythtv | |
| [20:13:41] | bedo1979 (bedo1979!~mbe@mbe.qpsk.net) has left #mythtv () | |
| [20:45:09] | SteveGoodey (SteveGoodey!~steve@host217-42-221-3.range217-42.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [21:29:38] | Warped (Warped!~Warped@108-85-161-113.lightspeed.cicril.sbcglobal.net) has quit (Ping timeout: 240 seconds) | |
| [21:33:24] | Jordack (Jordack!~Jordack@users.twp.ypsilanti.mi.us) has quit (Quit: My Recommendation in life: Do not get married and do not have kids.) | |
| [22:07:46] | wagnerrp: | dekarl: you mean your filesystem doesn't do that for you? |
| [22:35:51] | dekarl: | wagnerrp: the mythtv howto[tm] told me to use one filesystem per spindle ;) |
| [22:37:26] | dekarl: | or was that wrt optimizing the move across filesystems into a metadata operation? |
| [23:32:33] | wagnerrp: | "I'd like to see mythutil --moverecording, so SBE can record to a small buffer (SSD, small disk, NFS) then move the file to the "master storage system" in a post-recording-hook." |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.