| Wednesday, February 19th, 2014, 00:10 UTC | ||
| [00:10:50] | TheCras7 (TheCras7!~TheCrashe@p5080700F.dip0.t-ipconnect.de) has quit (Quit: KVIrc 4.3.1 Aria http://www.kvirc.net/) | |
| [00:17:12] | wahrhaft_ (wahrhaft_!~quassel@cpe-24-210-69-143.columbus.res.rr.com) has quit (Quit: No Ping reply in 180 seconds.) | |
| [00:17:58] | wahrhaft (wahrhaft!~quassel@cpe-24-210-69-143.columbus.res.rr.com) has joined #mythtv | |
| [00:33:39] | skd5aner: | jya_: not that it helps, but most of my livetv experiences have been extremely positive since I've resolved some of my hardware issues on my backend which was causing IO bottlenecks |
| [00:33:57] | jya_: | happy for you :) |
| [00:34:16] | jya_: | I'm writing a question on StackOverflow... it's very puzzling... |
| [00:34:33] | jya_: | look at my logs: |
| [00:34:34] | jya_: | http://pastebin.com/PTEKRbV9 |
| [00:34:52] | jya_: | so on one hand you have the writer writing happily, non stop |
| [00:35:01] | jya_: | then you have the reader reading by 64kB block |
| [00:35:26] | jya_: | 2014-02–19 11:24:10.256103 D FileRingBuf(/external/recordings/1001_20140219002351.mpg): read(65536) — begin is where it blocks |
| [00:36:12] | jya_: | you can see that the reader has reached the end of file where the writer last wrote. The writer has written 26934760 bytes; the reader has read so far 26930304 |
| [00:36:34] | jya_: | so the reader is 4456 bytes from the end of the file |
| [00:37:06] | jya_: | the next read of 64kB, as such returns early and has read 4456 bytes |
| [00:37:25] | jya_: | the following read of 64kB will no block, and will never come out of it |
| [00:37:39] | jya_: | yet, you see the writer continuing to write into the file forever |
| [00:38:00] | jya_: | 16s later the backend will abort the read and the frontend will disconnect |
| [00:39:50] | skd5aner: | you are going to know everything there is to know about NFS,the ring buffer, TFW, etc by the time you get to the bottom of this |
| [00:40:50] | jya_: | oh, I'm already past that point :) |
| [00:41:14] | jya_: | all problems have their upside I guess |
| [00:41:21] | jya_: | I want to solve this read problem... |
| [00:42:11] | jya_: | maybe if I feel like it, I will implement an internal cache, so the ringbuffer queries the TFW for data it is about to write so you don't need to write to a file, and read in another immediately in liveTV |
| [00:42:17] | jya_: | there'll be no lag |
| [00:43:06] | jya_: | have some kind of mechanisms that knows which file is being currently written to, where it's up to and query that data |
| [00:58:33] | jya_: | http://stackoverflow.com/questions/21868812/w . . . ocks-forever |
| [01:23:48] | andreaz (andreaz!~andre_000@p5DCA3126.dip0.t-ipconnect.de) has joined #mythtv | |
| [01:54:37] | DevWork_ (DevWork_!~DevWork@38.96.32.242) has quit (Read error: Connection reset by peer) | |
| [01:54:59] | arescorpio (arescorpio!~arescorpi@56-57-245-190.fibertel.com.ar) has quit (Ping timeout: 240 seconds) | |
| [02:33:57] | andreaz (andreaz!~andre_000@p5DCA3126.dip0.t-ipconnect.de) has quit (Read error: Connection reset by peer) | |
| [02:34:09] | sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Ping timeout: 252 seconds) | |
| [02:46:50] | sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv | |
| [02:49:53] | ** jya_ looks promising ** | |
| [03:32:27] | jya_: | I think I've nailed it |
| [03:33:32] | jheizer: | :) |
| [03:36:29] | wagnerrp_ (wagnerrp_!4ad75a64@gateway/web/freenode/ip.74.215.90.100) has joined #mythtv | |
| [03:40:04] | wagnerrp (wagnerrp!~wagnerrp_@mythtv/developer/wagnerrp) has quit (Ping timeout: 245 seconds) | |
| [03:40:25] | jya_: | and liveTv doesn't stutter anymore either. |
| [03:40:48] | jya_: | 2% more CPU usage ... hmmmm |
| [03:41:03] | jheizer: | Interested to read your next email about it. Topic has had me intrigued. Had just read your stackoverflow question. |
| [03:41:06] | Captain_Murdoch: | I'm not up to speed fully on the problem you're trying to troubleshoot, but isn't this the exact reason that we try not to play to the end of the file if it is an in-progress recording. seems like deja-vu. |
| [03:41:18] | Captain_Murdoch: | or maybe s/try/tried/ |
| [03:41:20] | jheizer: | It made me wonder if the reader was quietly closing on hitting EOF. |
| [03:41:59] | jya_: | Captain_Murdoch: the issue is that while we're behind EOF for playback; the read ahead thread is very close; and in fact usually ahead as it uses rather big block by default (470k right now) |
| [03:42:21] | Captain_Murdoch: | ah, so it defeated the purpose of staying behind. |
| [03:42:41] | Captain_Murdoch: | or caused us to not stay behind far enough. |
| [03:42:51] | jya_: | what I've noticed is that if you get into a read which hits EOF and so returns early, this is followed immediately by another read before another write occurred |
| [03:43:15] | jya_: | if you do a read right after one that reached EOF and no write in between, it may take up to 28s for the read to return |
| [03:43:16] | Captain_Murdoch: | I believe the timestretch code also has code in it to adjust back to 1.0 speed if we get too close to live. |
| [03:43:17] | peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Ping timeout: 252 seconds) | |
| [03:43:33] | jya_: | and the frontend would have dropped the connection by then as it hasn't received new data for too long |
| [03:43:45] | Captain_Murdoch: | yeah, just looked at your debug output. it makes sense totally. there's nothing to wake the read up. |
| [03:44:16] | jya_: | with several MB ring buffer size, you have to be pretty far from the end ! and with liveTV, that would make change of channel last several seconds |
| [03:45:05] | jya_: | the 2nd read didn't always lock for long; sometimes only a second or so only. but that caused liveTV to stutter whenever you were close to the end |
| [03:45:48] | jya_: | now I check the size in the file, and only read what there's to read, never try to read more; this has made liveTV extremely smooth... didn't expect that, I only wanted to prevent complete locking |
| [03:46:55] | jya_: | I'm still wondering if it wouldn't be worth to have a caching engine; like the reader query the writer where it's up to, and get the data from the writer instead of fetching it from the disk instead... |
| [03:46:57] | Captain_Murdoch: | you could modify that to only do the check if it knows it is close to the end to save some CPU cycles when you're nowhere near live. |
| [03:47:11] | jya_: | would allow to be exactly at the end of the file; no need for buffer and waits |
| [03:47:34] | jya_: | but how do you know inside the ring buffer how close you may be? |
| [03:47:52] | Captain_Murdoch: | keep track of the last known size. |
| [03:48:34] | jya_: | rewind and forward is almost instantaneous on my mac now... |
| [03:48:34] | Captain_Murdoch: | when you stat. then next time you go to read, if the last known size is greater than current position plus the read size then you don't need to stat again. |
| [03:48:52] | jya_: | yes... good idea... |
| [03:49:07] | jya_: | how much cycle would fstat needs though? |
| [03:49:20] | Captain_Murdoch: | shouldn't be much and should be in the fs cache I'd think. |
| [03:49:43] | Captain_Murdoch: | wasn't sure if that was part of the 2% you mentioned though. |
| [03:49:57] | jya_: | well, i'm starting to think its my extra log :) |
| [03:50:06] | peper03 (peper03!~peper03@mythtv/developer/peper03) has joined #mythtv | |
| [03:50:13] | jya_: | when I notice a failure, it takes me a good 5 minutes to find the origin point in the extremely verbose log |
| [03:50:27] | Captain_Murdoch: | :) that'd do it. |
| [03:53:35] | Captain_Murdoch: | nice job tracking that down. |
| [03:54:06] | ** Captain_Murdoch is afkobd (away from keyboard on baby duty) ** | |
| [03:54:08] | nyloc (nyloc!~quassel@p5B26FC29.dip0.t-ipconnect.de) has joined #mythtv | |
| [03:56:58] | DouglasKAway is now known as DouglasK | |
| [03:57:27] | jya_: | Captain_Murdoch: I've spent about $4k in extra equipment and about 1 month of frustration.... @#$@#%#% |
| [03:57:39] | jya_: | for something ultimately very simple |
| [03:58:20] | jya_: | starting to think that all the extra timings added here and there when we're playing liveTV are ultimately just work around and aren't necessary |
| [03:58:35] | _nyloc_ (_nyloc_!~quassel@p5B26FAB5.dip0.t-ipconnect.de) has quit (Ping timeout: 252 seconds) | |
| [04:10:55] | jheizer: | I don't have the issue but building with it in my test VM. I'll see if I can piss it off or not. |
| [04:14:18] | jya_: | testing that it doesn't introduce regression is valuable too |
| [04:17:19] | jheizer: | And more interesting than the work I am staying up late to do. |
| [04:20:21] | gnac (gnac!~gnac@or-71-0-52-80.sta.embarqhsd.net) has quit (Ping timeout: 248 seconds) | |
| [04:39:50] | fetzerch_ (fetzerch_!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 252 seconds) | |
| [04:41:26] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [05:11:09] | Goga777 (Goga777!~Goga777@128-71-38-64.broadband.corbina.ru) has joined #mythtv | |
| [05:30:59] | wagnerrp_: | i just installed java... i feel dirty |
| [05:31:13] | jheizer: | Assuming a HLS stream recording is a valid test, I can hold down skip forward and it doesn't mind. |
| [05:31:34] | jheizer: | Haev to take down my prod box to steal back a HDHR tuner |
| [05:31:42] | jheizer: | But it is busy. |
| [05:38:01] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!) | |
| [05:48:49] | tgm4883_ (tgm4883_!~tgm4883@ubuntu/member/tgm4883) has quit (Ping timeout: 245 seconds) | |
| [05:53:49] | tgm4883_ (tgm4883_!~tgm4883@ubuntu/member/tgm4883) has joined #mythtv | |
| [06:40:25] | DouglasK is now known as DouglasKAway | |
| [06:55:21] | SteveGoodey (SteveGoodey!~steve@host86-152-62-67.range86-152.btcentralplus.com) has joined #mythtv | |
| [07:00:45] | Goga777 (Goga777!~Goga777@128-71-38-64.broadband.corbina.ru) has quit (Remote host closed the connection) | |
| [07:04:08] | FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has joined #mythtv | |
| [07:05:03] | SteveGoodey (SteveGoodey!~steve@host86-152-62-67.range86-152.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [07:14:10] | jya_: | is there a windows buildbot ? |
| [07:14:31] | Tobbe5178 (Tobbe5178!~asdf@h104n2-sv-a13.ias.bredband.telia.com) has joined #mythtv | |
| [07:31:37] | wagnerrp_: | dbl ain runs one |
| [07:36:42] | stuartm: | https://code.mythtv.org/buildbot/builders/mas . . . c-2010-32bit https://code.mythtv.org/buildbot/builders/mas . . . -mingw-32bit |
| [07:37:21] | stuartm: | hmm, ignore the second one, seems it's offline |
| [08:30:13] | wagnerrp_ (wagnerrp_!4ad75a64@gateway/web/freenode/ip.74.215.90.100) has quit (Ping timeout: 245 seconds) | |
| [08:37:50] | stuartm: | dekarl: worth a try, if it works though we might want to try to apply that rule (division by multiples of two) to all content, since SD can be any resolution |
| [08:39:19] | stuartm: | it seems we're not taking into account/cropping the last four lines when the vertical resolution is 1084 |
| [08:46:11] | dekarl: | where does 1084 come from? I only know of 1088 due to 8 pixel blocks per field. 2*8 => 16 |
| [08:50:10] | dekarl: | also every format should have a way to signal that a 1080 visible picture inside a >1080 frame. I thought we had fixed most instances of reading from the wrong attribute |
| [08:53:17] | Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:2c82:f997:bb69:a19c) has joined #mythtv | |
| [09:01:04] | stuarta: | i'm going to kill off the mingw buildslave, it's been dead for about 6 months |
| [09:07:40] | stuartm: | dekarl: sorry, I meant 1088 ... knew something was wrong even as I said four lines and 1084, but I couldn't think what :) Not enough caffeine this morning |
| [09:08:24] | stuartm: | I quite often swap 4 and 8 in my mind ... |
| [09:08:26] | stuarta: | jya_: you shouldn't need a caching engine as the kernel should still have the data in buffer cache |
| [09:09:01] | jya_: | stuarta: I agree; except that as per all the trouble so far, it's not that straight forward |
| [09:09:28] | stuartm: | dekarl: we're not accounting for that crop requirement when transcoding for HLS |
| [09:10:45] | stuartm: | I have dirty green line across the bottom of the transcoded video in JW Player |
| [09:11:09] | stuarta: | i think that's why we trim off the bottom 4/8 pixels |
| [09:11:36] | dekarl: | Ahh ok, need to look why the transcode is not obeying the crop then. Or is the crop data missing in the recording? |
| [09:12:09] | stuarta: | i think it's one of those things where the tv itself is assumed to overscan slightly and therefore you would never see it anyway |
| [09:12:26] | stuarta: | so for things that don't overscan, you have to trim it |
| [09:12:58] | stuartm: | mythfrontend crops it correctly, but I don't know if that's because it's hardcoded to crop anything > 1080 or whether it's doing so because the metadata says it should |
| [09:13:33] | stuarta: | i suspect the first option |
| [09:13:37] | stuartm: | so do I |
| [09:13:42] | ** jya_ always being reminded that I should track how AirVideo calls ffmpeg to get perfect HLS transcoding ** | |
| [09:14:04] | jya_: | stuartm: you have content > 1080? |
| [09:14:13] | stuartm: | it's been a very long time since I looked at mpeg flags, |
| [09:14:38] | stuartm: | jya_: yes, most of the HD content is actually 1088, the last 8 lines are supposed to be ignored |
| [09:15:07] | jya_: | IRC, our call simply does something like: if (line == 1088) line = 1080 |
| [09:15:08] | stuartm: | most 1080 content is actually 1088 |
| [09:15:21] | jya_: | s/call/code/ |
| [09:15:24] | stuartm: | jya_: that's my recollection too |
| [09:16:18] | stuartm: | don't remember there being a crop flag for mpeg, a display aspect ratio and resolution yes, but not a flag which says 'discard these pixels' |
| [09:16:30] | dekarl: | https://code.mythtv.org/cgit/mythtv/tree/myth . . . ode.cpp#n394 ;) |
| [09:16:53] | stuartm: | dekarl: heh, nice find |
| [09:17:00] | stuartm: | I'll uncomment it |
| [09:17:28] | dekarl: | all interlaced MPEG-2 and all H.264 should have 1088 vertical pixels in the raw video frame due to the 2*8 or 16 pixel block size IIRC |
| [09:17:31] | stuartm: | although, need to check that it crops there |
| [09:17:34] | stuarta: | jya_: is the ringbuffer using non-blocking reads or blocking reads? |
| [09:17:35] | jya_: | stuartm: in Transcode::GetProfile, line 99 |
| [09:17:39] | jya_: | if (height == 1088) |
| [09:17:40] | jya_: | height = 1080; |
| [09:18:13] | jya_: | stuarta: it's a regular file, there's O_NONBLOCK would make zero difference. read() on a regular file should never be blocking |
| [09:18:50] | stuarta: | okay, so the issue is mainly that we weren't handling error conditions from the read properly? |
| [09:18:54] | jya_: | (I did first focus on that, as I thought that was the problem). Learnt something new then |
| [09:18:59] | stuartm: | jya_: that check is just to make sure that we pick the correct transcoding profile e.g. the user has defined a profile for 1080 video which should be applied even when the video is 1088 |
| [09:19:00] | jya_: | stuarta: neither |
| [09:20:01] | jya_: | sometimes (not always), if you do two read in a row, and the first read encountered EOF (so returned 0 or less than the amount of bytes you asked for), the second call will freeze |
| [09:20:18] | jya_: | even if right after that you have a write done. read() won't return for up to 30s |
| [09:20:30] | stuarta: | interesting |
| [09:20:32] | stuartm: | in this case, it's transcoding fine using the HLS profile, but it's failing to crop those lines so the result, even at 640x360 has a green line at the bottom |
| [09:20:40] | jya_: | not always the case... sometimes it blocks for 2–3s... |
| [09:21:00] | jya_: | I haven't had any "read is taking a long time" type of message since I've done that |
| [09:21:04] | stuarta: | i wonder if those numbers tie in with the default sync interval for the kernel |
| [09:21:06] | dekarl: | looking at transcode.cpp there are lots of places where the dimensions for the codec and for the visible picture appear to be messed up :( |
| [09:21:20] | jya_: | use to always have those in liveTV, the workaround was to press pause or rewind 10–15s if you remember |
| [09:21:30] | stuarta: | the similarities are just too big to be a coincidence |
| [09:21:46] | stuarta: | yep, remember that workaround |
| [09:21:56] | jya_: | stuarta: nah, I made synchronous sync after the write, open the file in write mode with O_SYNC... nothing changed |
| [09:22:05] | jya_: | for a few days I thought the problem was in the TFW |
| [09:22:17] | stuarta: | that is odd |
| [09:22:32] | stuarta: | and this is all local fs too isn't it? |
| [09:22:45] | jya_: | well, now, liveTV is really perfect, I get no stutter of any kind. If reduced the automatic wait that was added so we wouldn't be so closed to the end |
| [09:22:55] | jya_: | and it's still working just fine |
| [09:22:59] | stuarta: | nice one |
| [09:23:05] | jya_: | stuarta: either local FS or NFS |
| [09:23:36] | jya_: | I'll let this one sit a bit, after that I'm going to remove all the wait and pre-buffering that was added over the year to fix liveTV |
| [09:23:51] | jya_: | can't believe something so dumb has caused so much grief for so long |
| [09:23:58] | stuarta: | does it make sense to commit what you have done so far? |
| [09:24:07] | jya_: | Just about to in master |
| [09:24:11] | stuarta: | jya_: i can completely believe it |
| [09:24:28] | jya_: | I'll run the version for fixes/0.27 for a few days and back port it then |
| [09:24:45] | jya_: | liveTV has been a sore point for us for a long time... |
| [09:24:50] | stuarta: | it's a symptom of not completely understanding what is going wrong, so the "fix" is merely a bodge which kinda works |
| [09:25:18] | jya_: | there's no many sleep in that code here and there... it's rather surprising |
| [09:25:30] | stuarta: | i'm really curious about this up to 30s lag, might have to try and reproduce it |
| [09:25:53] | stuarta: | sleep = bad |
| [09:26:53] | jya_: | I haven't been able to reproduce it in my unit test... but now I think I know of a way... I was writing in 64kB block (like TFW does). Changing the read size to 64kB much improved the problem... it would take sometime several hours to reproduce the problem |
| [09:27:15] | jya_: | and in my unit test, the reader don't really try to go much faster than the writer |
| [09:27:26] | jya_: | stuarta: usleep actually :) |
| [09:29:15] | jya_: | well, in liveTV going from one program to the next doesn't cause the frontend to exit on my mac anymore; but it still plays up 10–15s |
| [09:31:15] | stuarta: | that's an improvement at least |
| [09:31:52] | jya_: | it's close to not-noticeable on my main frontend |
| [09:39:27] | stuartm: | jya_: for me the biggest issue is that when it gets into any sort of error state, it often results in it locking up completely after several minutes of spewing the same error in an inescapable loop |
| [09:39:51] | jya_: | is that during livetv? |
| [09:39:57] | jya_: | on the FE or the BE? |
| [09:40:19] | jya_: | the handling of the FE when the BE drops the connection is .... poor to say the least |
| [09:40:43] | ** stuarta awards jya_ "understatement of the year" award ** | |
| [09:41:01] | stuartm: | jya_: FE, livetv but sometimes with recordings or DVDs if it hits a period of corruption that it tries to struggle past (damaged DVD, signal interference etc) |
| [09:41:10] | jya_: | during the read from the frontend via myth:// protocol, if on the BE safe_read() started blocking, after 16s the BE abort, and just drops the lot. the FE rarely recovered from there |
| [09:41:37] | stuartm: | the error handling is pretty much broken, because it's probably not been tested in years while the code around it has changed significantly |
| [09:42:11] | stuarta: | should be fairly easy to inject errors using iptables to drop packets |
| [09:42:38] | jya_: | on the frontend, in the log, usually sees stuff like: 2014-02–19 10:13:39.819074 E decoding error eno: Operation not permitted (1) |
| [09:42:56] | jya_: | that's until you kill it, as it's not responsive to user events |
| [09:43:29] | jya_: | 1000s of them |
| [09:43:56] | stuartm: | for fe<>be communication yes, the video decoding error issues would need some reliable samples – preferably ones that we can build into a mandatory QA process at least once a cycle but hopefully more frequently so that errors are caught early |
| [09:44:41] | jya_: | logs from earlier in the day when the backend timedout |
| [09:45:26] | jya_: | stuartm: but this video decoding error are due to the BE dropping the connection, and the FE is now returning early on a read and feed garbage to avfd |
| [09:45:54] | jya_: | http://pastebin.com/CVjWSYwE that's a session after the BE timed-out trying to read the file |
| [09:45:57] | stuartm: | jya_: yeah we're talking about two different issues |
| [09:47:07] | jya_: | well, let me know if you are still seeing those issues with the changes I'm about to push... while that won't fix the FE handling of errors, I believe there should be far less of those |
| [09:47:39] | stuartm: | jya_: right, we should be null terminating the data or similar so that we know when the data we've got is incomplete and should be discarded |
| [09:47:41] | jya_: | i have pretty good signal here since I've changed the antenna, so I see very little corruption of media |
| [09:48:43] | stuarta: | move /home on alcor to it's own dedicated LV |
| [09:48:48] | stuarta: | *moved |
| [09:48:52] | jya_: | but I do remember when it struggle on a few frames, it then try to recover A/V sync by dropping frames here and there. it always end up crapping things up and it never recovers. But it continues to just drop ever second frame |
| [09:48:59] | nyloc (nyloc!~quassel@p5B26FC29.dip0.t-ipconnect.de) has quit (Ping timeout: 240 seconds) | |
| [09:49:07] | stuartm: | jya_: I don't often use livetv and stichnot's recent changes did reduce the frequency of any problems, in fact it's more likely that I'll be able to reproduce the 'stuck in an error loop' issue with a damaged DVD (rent through the post, so I receive a few of those each year) |
| [09:51:29] | jya_: | I can't say I've ever seen much improvements with stichnot changes. quite the opposite unfortunately |
| [09:52:07] | stuartm: | the sort of stuff I see is endless "waited X seconds for decoder to pause" |
| [09:53:25] | stuartm: | and "Failed to stop decoder loop" |
| [09:56:51] | nyloc (nyloc!~quassel@p3EE2CE68.dip0.t-ipconnect.de) has joined #mythtv | |
| [10:01:49] | stuartm: | which usually occurs after I've hit ESCAPE, because it's been spewing av sync or prebuffering pause errors for a few minutes |
| [10:03:04] | stuartm: | escape or pause, once you see "Failed to stop decoder" or similar, it's time to kill the frontend because it's truly wedged |
| [10:06:13] | jya_: | yeah, that's the other way it locked up... just had that right after |
| [10:06:13] | jya_: | http://pastebin.com/Vy5ghhyx |
| [10:07:13] | jya_: | damn, got another issue, this time with full local files... |
| [10:07:53] | jya_: | oh... same bug, but the frontend I'm using haven't been patched. |
| [10:37:22] | stuarta: | curious 49.9% of mythtv users are still running fixes/0.25 |
| [10:37:41] | stuarta: | only 8.8% on fixes/0.27 |
| [10:39:50] | jya_: | personally, I've never ran the thing uploading my config (it always errored one way or another) |
| [10:40:02] | jya_: | what are the remaining 40% running ? |
| [10:41:58] | stuarta: | 5.4% on 0.26, 34.7% unknown |
| [10:42:05] | stuarta: | and a few stragglers |
| [10:42:21] | stuarta: | amuse yourself http://smolt.mythtv.org |
| [10:42:33] | jya_: | done... one |
| [10:43:43] | jya_: | i need myth browser installed to watch the result |
| [10:43:52] | jya_: | looking at this hostname |
| [10:44:06] | jya_: | why is it forum.mythtv.org and not forums.mythtv.org ? |
| [10:44:26] | ** stuarta shrugs ** | |
| [10:44:31] | jya_: | I'm pretty sure most places I've using are forums. |
| [10:44:43] | jya_: | even in the menu bar at the top, it's forums, not forum |
| [10:45:00] | stuarta: | it's easy enough to get that added to everyone gets to the right place |
| [10:45:08] | jya_: | yeah :) |
| [10:45:19] | jya_: | in smelt, what's an "active host" ? |
| [10:45:40] | stuarta: | no idea, have to ask jams_ |
| [10:46:54] | jya_: | what could be "unknown" as version number ? |
| [10:47:02] | jya_: | that's 34% of them |
| [10:48:44] | dekarl: | stuarta, the reporting of fixes/0.27 was just fixed lately... |
| [10:49:33] | stuarta: | dekarl: were they unknown before that? |
| [10:49:52] | dekarl: | completely Missing, Unknown etc pp |
| [10:50:23] | warpme (warpme!~piotro@bog193.neoplus.adsl.tpnet.pl) has joined #mythtv | |
| [10:51:03] | dekarl: | http://pastebin.com/SLNMGLV4 |
| [10:53:23] | dekarl: | stuarta, https://code.mythtv.org/cgit/mythtv/log/mytht . . . dwareprofile |
| [10:54:50] | dekarl: | looking forward to the patches to the MacOSX build to make it into the tree. IIUIC that user got the Python bindings and Smolt running easily |
| [10:55:35] | jya_: | trying to submit a profile and I get: "reContext mythdb.cpp:183 (DBError) DB Error (HouseKeeperTask::updateLastRun):#012Query was:#012INSERT INTO housekeeping ( tag, hostname, lastrun) VALUES (?, ?, ?)#012Bindings were:#012:HOST="mediaserver-surrey1.bubblestuff.com", :TAG=" HardwareProfiler",#012:TIME=2014-02–19T10:54:53Z#012Driver error was [2/1062]:#012QMYSQL3: Unable to execute statement#012Database error was:#012Duplicate entry |
| [10:55:36] | jya_: | 'HardwareProfiler-mediaserver-surrey1.bubblestuff.com' for key 'task' |
| [10:55:47] | jya_: | sphery: need your wisdom on mysql |
| [10:57:24] | jya_: | dekarl: unfortunately, running python script from OSX has proven more difficult than I first predicted. i did got the grabber and other metadata tools to work. but never looked into smolt |
| [10:58:09] | dekarl: | verm__ has been doing something on it http://irc.mythtv.org/ircLog/channel/4/2014-01-28:14:58:41 |
| [11:02:41] | Goga777 (Goga777!~Goga777@128-71-38-64.broadband.corbina.ru) has joined #mythtv | |
| [11:11:17] | jya_: | dekarl: the issue with python is that each version of mac os comes with a different version of python, and each of them was compiled so that only modules built for *that* particular python version will work. so 10.7 and 10.8 both comes with 2.6. but compile and install one of the python dependency required by myth, and the module will refuse to load with python 2.7 on OS 10.8 |
| [11:11:32] | jya_: | they have changed the ABI number between release. |
| [11:12:00] | jya_: | currently the advantage of the OS X package, is that they run on all version of OS X from 10.6. So 10.6, 10.7, 10.8 and 10.9 |
| [11:12:23] | jya_: | but the python binding would only work on the version myth was compiled on |
| [11:26:46] | stuartm: | stuarta: some of that correlates with the fact that they are using distros which only have 0.25 in official repos, e.g. to get 0.26 and 0.27 on Ubuntu you need to enable the third party mythbuntu repo which a lot of users never seem to discover for themselves |
| [11:29:28] | stuartm: | and some is just people sticking with what works for them, not wanting to risk an upgrade that might break something |
| [11:42:10] | jya_: | only 1s for live TV playback behind live, and not a stutter... very happy |
| [11:42:34] | stuartm: | jya_: fantastic! |
| [11:42:50] | stuartm: | can't wait to try it out |
| [11:43:21] | jya_: | with the current change to the ring buffer has it at about 2–3s behind only |
| [11:44:05] | jya_: | those girls on bobsleigh are so muscly... it's scary |
| [11:45:02] | doev (doev!~doev@p4FD42C2E.dip0.t-ipconnect.de) has joined #mythtv | |
| [11:46:35] | stuarta: | stuartm: and if i remember right 0.26 was a bit shaky |
| [11:47:53] | jya_: | yeah, heaps of call telling people to stick to 0.25 |
| [11:50:15] | stuartm: | never had a problem with 0.26 personaly :/ |
| [11:50:46] | stuarta: | it's so long ago i can't remember |
| [11:51:05] | stuarta: | but i don't recall anything specific |
| [11:54:15] | jya_: | mostly with hdpvr i believe |
| [11:54:21] | dekarl1 (dekarl1!~dekarl@p4FCEF664.dip0.t-ipconnect.de) has joined #mythtv | |
| [11:55:50] | dekarl (dekarl!~dekarl@p4FCEFDB9.dip0.t-ipconnect.de) has quit (Read error: Operation timed out) | |
| [12:01:05] | stuartm: | trouble now seems to be with iptv :/ |
| [12:01:54] | stuarta: | i do sometimes wonder if we would be better using iptv protocols to transport data from the backend, rather than some myth specific protocol |
| [12:03:00] | stuarta: | </random_idea> |
| [12:04:03] | warpme (warpme!~piotro@bog193.neoplus.adsl.tpnet.pl) has quit (Quit: warpme) | |
| [12:09:36] | FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has quit (Quit: FabriceMG) | |
| [12:14:25] | FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has joined #mythtv | |
| [12:35:05] | dekarl1 is now known as dekarl | |
| [12:35:31] | dekarl: | stuartm, what IPTV trouble? |
| [12:35:33] | jya_: | what trouble ? |
| [12:35:37] | jya_: | LOL |
| [12:35:45] | dekarl: | The only regression I know is that we lost RTCP support |
| [12:35:58] | dekarl: | so no freebox.fr with fixes/0.27 |
| [12:36:19] | dekarl: | (I'm not even sure that this really is the root cause, maybe its just a coincidence) |
| [12:36:49] | dekarl: | Oh, and the "mpeg-ts via http support" patch does not apply anymore |
| [12:38:11] | dekarl: | Oh, and the "RTP receiption is broken" ticket, but I'm not sure if they are really getting RTP or plain MPEG-TS over UDP |
| [12:39:50] | dekarl: | Free.FR timeout https://code.mythtv.org/trac/ticket/11949 |
| [12:39:50] | dekarl: | MPEG-TS over HTTP patch https://code.mythtv.org/trac/ticket/11487 |
| [12:39:50] | dekarl: | RTP receiption broken https://code.mythtv.org/trac/ticket/11852 |
| [12:40:43] | dekarl: | note to self, teach the bot to paste the summary from tickets... (have we got the xmlrpc api patch enabled on trac?) |
| [12:48:07] | joki (joki!~joki@p5486163D.dip0.t-ipconnect.de) has quit (Ping timeout: 265 seconds) | |
| [12:56:41] | FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has quit (Quit: FabriceMG) | |
| [13:00:27] | FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has joined #mythtv | |
| [13:01:18] | ubuntu (ubuntu!~smuxi@195.59.102.83) has joined #mythtv | |
| [13:01:27] | ubuntu is now known as MartinT | |
| [13:11:30] | MartinT (MartinT!~smuxi@195.59.102.83) has quit (Remote host closed the connection) | |
| [13:14:57] | nyloc (nyloc!~quassel@p3EE2CE68.dip0.t-ipconnect.de) has quit (Read error: Operation timed out) | |
| [13:17:03] | nyloc (nyloc!~quassel@p57B4FCC9.dip0.t-ipconnect.de) has joined #mythtv | |
| [13:24:25] | jya_: | dekarl: i'm fairly certain i read someone got their free box to work with myth in 0.27 |
| [13:29:29] | andreaz (andreaz!~Andreaz@tmo-107-43.customers.d1-online.com) has joined #mythtv | |
| [13:43:50] | dekarl: | jya_: I'm not finding anything on the TV interface that we could use. https://www.google.de/search?&q=freebox+api has lots of API stuff but only related to other services. I was hoping that we can tap directly into the Free Router without needing their Free STB (or whatever they call the boxes) |
| [13:44:34] | jya_: | you simply need to use the playlist available on their site and use that |
| [13:44:58] | dekarl: | Oh, I thought the site is one the STB/Router |
| [13:45:24] | jya_: | it is |
| [13:45:33] | jya_: | have you tried the instructions there? http://www.mythtv.org/wiki/FreeBox |
| [13:45:48] | jya_: | pity i was in france for a month for christmas, didn't think of trying |
| [13:46:53] | stuarta: | we might have some success asking in #mythtv-users for anybody on free.fr that could lend a hand |
| [13:49:04] | dekarl: | nvm, I was thinking of "Complex case, without the Freebox modem" when I said without STB |
| [13:50:56] | jya_: | dekarl why would anyone ever use free these days without the free box ? |
| [13:51:17] | dekarl: | oh, which has nothing to do with free.fr but is the generic "use vlc as streaming server" use case |
| [13:51:43] | jya_: | it's free; has 1000s of options, free TV channels, free phone to most places in the world, a bluray player, the list goes on |
| [13:52:21] | dekarl: | jya_ the wiki led me to believe that it has a link to a guide on using the free tv service without the modem... when actually its a guide on using our Freebox Recorder for unrelated services |
| [13:52:58] | jya_: | yeah, that's very obsolete... there used to be a time you could use free without their modem. these days I don't believe that's an option |
| [13:53:17] | jya_: | knowing that their router can act as full bridge, so you can use your own router |
| [13:53:47] | jya_: | the TV settings are via a private vlan, will be a pain to emulate |
| [13:54:20] | jya_: | all right... off to bed... |
| [13:55:36] | stuarta: | nn |
| [14:01:48] | Goga777 (Goga777!~Goga777@128-71-38-64.broadband.corbina.ru) has quit (Quit: Leaving) | |
| [14:17:20] | stuartm: | stuarta: might be worth asking in the France forum too |
| [14:17:58] | stuartm: | especially since one of the mods could translate the request into French and repeat it at the French community website |
| [14:19:39] | stuarta: | yes that's good idea too |
| [14:20:00] | jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya) | |
| [14:20:00] | jya_ is now known as jya | |
| [14:37:07] | DouglasKAway is now known as DouglasK | |
| [15:27:08] | stuarta: | stuartm: can we get the GA id changed @tapatalk please? |
| [15:29:01] | stuartm: | stuarta: done |
| [15:29:55] | stuartm: | hmm, wait, was that the right one ... UA-6891668–3? |
| [15:30:25] | stuartm: | nope, fixed |
| [15:30:54] | stuarta: | -4 |
| [15:30:59] | stuarta: | thanks |
| [15:31:27] | stuartm: | yeah, was looking at the wrong log |
| [15:31:51] | stuarta: | cheers |
| [15:32:16] | stuarta: | now i just need somebody to use it |
| [15:33:45] | stuartm: | they've just released a new plugin version, but I'll wait until the weekend before I upgrade to it |
| [15:34:12] | ** jheizer browsing via tapatalk ** | |
| [15:36:16] | stuartm: | there's one worthwhile change in the new version, which is that you can disable in-app registration and forward people to the forum registration page instead – since we're requiring people to indicate which country they are in, and that can't be done in-app, we'll probably want to use that option |
| [15:36:38] | stuarta: | nice |
| [15:36:41] | jheizer: | browsed a dozen or so threads. |
| [15:36:44] | jheizer: | make some data |
| [15:36:58] | stuarta: | jheizer: it'll probably take some time to work it's magic |
| [15:56:02] | stuartm: | not sure how well it works, tapatalks own stats showing 0 users and 0 posts, which I know isn't true |
| [15:56:24] | stuarta: | possibly aggregated daily, so we won't see until tomorrow |
| [16:30:50] | FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has quit (Quit: FabriceMG) | |
| [16:47:48] | stuarta: | hmmm, i think load testing smolt broke it |
| [16:50:11] | stuarta: | ah well, a quick restart fixes that |
| [16:53:02] | jafa (jafa!~jafa@2001:470:1f05:1cf5:cc7d:d552:74fd:ecf1) has quit (Ping timeout: 264 seconds) | |
| [17:04:09] | jafa (jafa!~jafa@2001:470:1f05:1cf5:2c35:e602:1b2e:8ddd) has joined #mythtv | |
| [17:24:21] | doev (doev!~doev@p4FD42C2E.dip0.t-ipconnect.de) has quit (Ping timeout: 248 seconds) | |
| [17:25:27] | NightMonkey (NightMonkey!~NightrMon@173-164-139-193-SFBA.hfc.comcastbusiness.net) has joined #mythtv | |
| [17:25:42] | NightMonkey (NightMonkey!~NightrMon@173-164-139-193-SFBA.hfc.comcastbusiness.net) has quit (Changing host) | |
| [17:25:42] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [17:27:37] | Goga777 (Goga777!~Goga777@128-71-38-64.broadband.corbina.ru) has joined #mythtv | |
| [17:32:29] | wagnerrp (wagnerrp!4ad75a64@gateway/web/freenode/ip.74.215.90.100) has joined #mythtv | |
| [17:40:02] | wagnerrp (wagnerrp!4ad75a64@gateway/web/freenode/ip.74.215.90.100) has quit (Quit: Page closed) | |
| [17:43:22] | wagnerrp (wagnerrp!~wagnerrp_@mythtv/developer/wagnerrp) has joined #mythtv | |
| [17:54:00] | andreaz (andreaz!~Andreaz@tmo-107-43.customers.d1-online.com) has quit (Read error: Connection reset by peer) | |
| [17:58:33] | Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:2c82:f997:bb69:a19c) has quit (Quit: Leaving) | |
| [18:17:23] | paul-h (paul-h!~Paul@90.216.190.16) has joined #mythtv | |
| [18:34:58] | natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has joined #mythtv | |
| [18:39:50] | SteveGoodey (SteveGoodey!~steve@host217-42-221-118.range217-42.btcentralplus.com) has joined #mythtv | |
| [18:40:02] | paul-h: | stuartm: my problem with the duplicate channels looks like it was caused by having a videosource that wasn't connected to any capturecard or cardinput |
| [18:40:08] | paul-h: | I deleted the old unused videosources and all seems well now :) |
| [18:41:12] | paul-h: | It does beg the question why is mythfilldatabase even bothering with videosources that aren't being used anywhere? |
| [18:47:46] | stuartm: | paul-h: yeah, we should fix that |
| [18:53:43] | rsiebert (rsiebert!~quassel@g229105137.adsl.alicedsl.de) has quit (Read error: Operation timed out) | |
| [18:54:49] | rsiebert (rsiebert!~quassel@g231196032.adsl.alicedsl.de) has joined #mythtv | |
| [19:07:23] | andreaz (andreaz!~andre_000@p5DCA3126.dip0.t-ipconnect.de) has joined #mythtv | |
| [19:30:35] | Goga777 (Goga777!~Goga777@128-71-38-64.broadband.corbina.ru) has quit (Remote host closed the connection) | |
| [19:44:55] | paul-h (paul-h!~Paul@90.216.190.16) has quit (Quit: Konversation terminated!) | |
| [20:09:18] | warpme (warpme!~piotro@bog193.neoplus.adsl.tpnet.pl) has joined #mythtv | |
| [20:55:43] | Steve-Goodey (Steve-Goodey!~SteveGood@host217-42-221-118.range217-42.btcentralplus.com) has joined #mythtv | |
| [21:08:10] | Seeker` (Seeker`!~cjo20@unaffiliated/seeker) has quit (Remote host closed the connection) | |
| [21:09:58] | Seeker` (Seeker`!~cjo20@host86-164-178-196.range86-164.btcentralplus.com) has joined #mythtv | |
| [21:09:58] | Seeker` (Seeker`!~cjo20@host86-164-178-196.range86-164.btcentralplus.com) has quit (Changing host) | |
| [21:09:58] | Seeker` (Seeker`!~cjo20@unaffiliated/seeker) has joined #mythtv | |
| [22:07:35] | Steve-Goodey (Steve-Goodey!~SteveGood@host217-42-221-118.range217-42.btcentralplus.com) has quit (Quit: Steve-Goodey) | |
| [22:08:43] | DouglasK is now known as DouglasKAway | |
| [22:21:22] | SteveGoodey (SteveGoodey!~steve@host217-42-221-118.range217-42.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [22:31:09] | gigem_: | jya: Congrats on nailing the livetv issue. Is your change applicable to 0.27 too? I suspect it is, but thought I'd ask anyway. My niece is a big user of livetv on my mom's mythtv system. |
| [22:31:17] | gigem_ is now known as gigem | |
| [23:01:29] | Tobbe5178 (Tobbe5178!~asdf@h104n2-sv-a13.ias.bredband.telia.com) has quit (Read error: Connection reset by peer) | |
| [23:22:48] | jya: | gigem: I entirely developed it on 0.27; I believe it will apply on 0.26 too. And on 0.25 with minor changes (due to the locking changes) |
| [23:22:56] | andreaz (andreaz!~andre_000@p5DCA3126.dip0.t-ipconnect.de) has quit (Read error: Connection reset by peer) | |
| [23:24:16] | warpme: | jya: sorry for maybe stupid q – but what means Your statement in http://www.gossamer-threads.com/lists/mythtv/users/564294#564294 ? |
| [23:24:52] | jya: | it means there's a coding error |
| [23:25:33] | warpme: | jya: should I change to "current_pos += ret;"? |
| [23:25:40] | jya: | what it means is that if it encounter an EOF, it won't actually resume reading . So it will exit after 360ms , after which the ring buffer will call it again |
| [23:25:59] | jya: | it should yes... but I've done it another way as we don't really need current_pos variable after all. |
| [23:32:31] | warpme: | jya: this whole situation with #12045 is interesting...I have perfectly working LiveTV with current 0.27-fixes. This hints me that there are probably some fixes in newer kernels in respect to read beyond EOF "block". I'm wonder what will happen when You will use 3.13 kernel with original MythTV code (no 12045 patch) in Your environment... |
| [23:32:31] | ** MythLogBot http://code.mythtv.org/trac/ticket/12045 ** | |
| [23:33:09] | jya: | warpme: it's probably the case. though I've tried every single kernel release since 3.2 and it made no difference |
| [23:33:22] | jya: | same with 3.13 |
| [23:33:34] | jya: | 3.13.3 I tried |
| [23:34:18] | jya: | warpme: are you using live TV with a remote frontend (different machine than the backend) or not using local files ? |
| [23:34:25] | warpme: | jya: hmm – how this can be?. |
| [23:35:03] | warpme: | jya: I have headless BE + 3 remote FE. I'm using exclusively myth protocol. |
| [23:35:11] | jya: | ok... |
| [23:35:38] | jya: | maybe it happens more when using NFS or slower media (I was using mdadm raid5 + lvm + jfs) |
| [23:37:38] | warpme: | jya: at some point of time I was suspecting exactly this area. Thats why I propose test with locally attached HDD without any additional components beyond filesystem w(i.e. EXT3). |
| [23:39:19] | jya: | warpme: I'm not messing with this any longer to be honest. The bug occurred in the two difference scenario I would use: RAID5+JFS or NFS/ZFS |
| [23:39:36] | natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has quit (Read error: Operation timed out) | |
| [23:39:41] | jya: | so I wouldn't gain much in trying on a different setup that I won't use just to verify a theory. |
| [23:39:53] | jya: | I have a curious mind, but not that much :) |
| [23:40:28] | warpme: | jya: it is great that You have now perfectly working LiveTV. On the other hand we still don't know root cause. While spending more energy on #12045 is probably not worth – whole situation shows me that we are lacking "reference" setup... |
| [23:40:28] | ** MythLogBot http://code.mythtv.org/trac/ticket/12045 ** | |
| [23:41:53] | jya: | warpme: I see that you've assigned yourself a task then :) |
| [23:42:17] | jya: | actually, google about the read and EOF situation |
| [23:42:44] | warpme: | jya: btw: I wan to play little with LiveTV speed-up channel changing. May You point me to places in code where I can remove not-needed-now delays? |
| [23:42:47] | jya: | it seems that calling read again after an EOF, is undefined behaviour. It may returns immediately 0 again, or may not |
| [23:43:14] | jya: | warpme: in ring buffer you have settings about fill_min |
| [23:43:19] | jya: | those can be removed |
| [23:43:43] | jya: | there are also some usleep at startup, that too can be removed |
| [23:44:04] | warpme: | jya: intact I was thinking since some time about such reference platform :-) |
| [23:44:10] | jya: | but even without nothing, my mac used to start about 15–20s after live. |
| [23:44:33] | jya: | now it always start after only 4–5s |
| [23:44:33] | warpme: | s/intact/infact/ |
| [23:44:52] | jya: | my linux frontend starts 3s after live only |
| [23:45:17] | jya: | this is better than I have ever had with live TV. So my guess is that reading after EOF always introduced some delays |
| [23:45:52] | warpme: | jya: 3s is nice. I'm guessing this is with local file mode for LiveTV – not with myth protocol – right? |
| [23:46:00] | jya: | no no. |
| [23:46:03] | jya: | with myth protocol |
| [23:46:12] | jya: | my BE is headless |
| [23:46:13] | warpme: | jya: whoa! |
| [23:46:14] | jya: | no frontend |
| [23:46:31] | jya: | it used to be about 10s behind |
| [23:47:13] | jya: | why don't you try the ring buffer change and test and let me know if you notice a difference |
| [23:47:58] | jya: | mind you, I always had an issue , and had that one since some changes to live TV was made in 0.25. That is when I started liveTV, I had to press pause or rewind 10s to get smooth playback |
| [23:48:03] | warpme: | jya: I'm out of home till Sat. Definitelly will try it ASAP. I already compile all patches via SSH to home machine – just can't test it :-( |
| [23:50:15] | DouglasKAway is now known as DouglasK | |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.