| Friday, February 15th, 2013, 00:04 UTC | ||
| [00:04:39] | jya: | code.mythtv.org is down? |
| [00:04:53] | jya: | ah no… just very very slow |
| [00:06:34] | danielk222: | It's slow for me too, but the load on the system is very low. |
| [00:07:00] | jya: | it takes about 5 minutes after I click on a patch before it shows up |
| [00:07:41] | jya: | www.mythtv.org is just as slow |
| [00:08:00] | jya: | the wiki that is |
| [00:08:31] | jya: | ah all good now |
| [00:09:07] | tgm4883 (tgm4883!~tgm4883@ubuntu/member/tgm4883) has joined #mythtv | |
| [00:11:45] | stichnot (stichnot!~stichnot@adsl-68-127-102-161.dsl.pltn13.pacbell.net) has joined #mythtv | |
| [00:11:45] | stichnot (stichnot!~stichnot@adsl-68-127-102-161.dsl.pltn13.pacbell.net) has quit (Changing host) | |
| [00:11:45] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [00:11:58] | danielk222: | The apache log has a lot of instances of this: http://code.google.com/p/modwsgi/issues/detail?id=197 — fixed in python 3.3 but apparently harmless other than the log spam (multiple messages per second). |
| [01:15:45] | TandyUK (TandyUK!~James@office.tandyukservers.co.uk) has joined #mythtv | |
| [01:15:50] | James2 (James2!~James@office.tandyukservers.co.uk) has quit (Read error: Connection reset by peer) | |
| [01:39:42] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 264 seconds) | |
| [01:50:06] | Seeker`: | jya: stuartm: Doing a find/replace in mythraopconnection.cpp/.h, replacing NetStream with RAOPNetStream fixed the problem I was having with Airplay causing segfaults when playback was stopped. My problem with Interactive TV (I.e. iplayer over freesat) segfaulting has also disappeared, although I haven't checked whether this was fixed in a previous commit yet |
| [01:50:25] | Seeker`: | It would make sense if the interactive TV bug was caused by the same thing though (namespace conflict) |
| [01:53:45] | Seeker`: | http://paste.ubuntu.com/1654796/ <- diff |
| [02:02:36] | tgm4883 (tgm4883!~tgm4883@ubuntu/member/tgm4883) has quit (Quit: ZNC - http://znc.in) | |
| [02:03:07] | tgm4883 (tgm4883!~tgm4883@ubuntu/member/tgm4883) has joined #mythtv | |
| [02:04:26] | joki (joki!~joki@p54863F51.dip.t-dialin.net) has quit (Ping timeout: 255 seconds) | |
| [02:04:43] | joki- (joki-!~joki@p548640D9.dip.t-dialin.net) has joined #mythtv | |
| [02:04:51] | joki- is now known as joki | |
| [04:08:52] | wagnerrp: | jya, danielk222: i saw something similar about a week ago |
| [04:09:10] | wagnerrp: | very low load on the system, plenty of memory available, painfully slow http server |
| [04:09:29] | wagnerrp: | i did notice the occasional zombified httpd when it was happening |
| [04:10:00] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 260 seconds) | |
| [04:11:01] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [04:26:24] | coling (coling!~colin@cpc7-sgyl36-2-0-cust267.18-2.cable.virginmedia.com) has quit (Ping timeout: 256 seconds) | |
| [04:26:44] | coling (coling!~colin@cpc7-sgyl36-2-0-cust267.18-2.cable.virginmedia.com) has joined #mythtv | |
| [04:46:35] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [04:49:39] | stichnot: | taylorr: sample is https://docs.google.com/file/d/0BxETmfuHvGPQM . . . ?usp=sharing , seektable from the recorder is http://pastebin.com/gu7nSMw1 , seektable from mythcommflag is http://pastebin.com/kXVc2PLn |
| [04:50:05] | stichnot: | I haven't had a chance to look at ffprobe yet |
| [04:50:36] | taylorr: | stichnot: thanks, now I can't go to sleep ;) |
| [04:54:05] | MaverickTech (MaverickTech!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Quit: Leaving) | |
| [05:05:15] | stichnot: | :) |
| [05:19:59] | taylorr: | stichnot: very strange findings – seems that the frame number is correct for the recorder and the byte position is correct for mythcommflag ;) |
| [05:20:41] | taylorr: | one thing to note is that the frame number in the seektable is the decoder order and not the presentation order |
| [05:24:35] | taylorr: | stichnot: is there any debug logging for mythcommflag? |
| [05:32:47] | taylorr: | setting "-v all --loglevel debug" doesn't show any additional output |
| [05:33:54] | taylorr: | for some reason the libraries don't output anything. |
| [05:51:08] | taylorr: | stichnot: do you know where in the code we get the byte position for the keyframe and then store it into the DB? |
| [06:01:00] | jpabq: | taylorr: when recording? libs/libmythtv/mpeg/H264Parser.cpp : H264Parser::addBytes() consumes bits and sets a state when a keyframe is detected. libs/libmythtv/recorders/dtvrecorder.cpp : DTVRecorder::FindH264Keyframes detects that state, and stores the offset of the "payload" that contains the keyframe in the DB. |
| [06:02:55] | jpabq: | During a commflag --rebuild, I believe it is actually parsing the video using ffmpeg, and using ffmpeg to determine the offset of the frame — however I have not really looked at that code. |
| [06:09:37] | taylorr: | jpabq: thanks, for mythcommflag we basically set up a player with no video output and keep track of frames read and played so it's not purely ffmpeg processing |
| [06:10:55] | jpabq: | Honestly, I didn't even think to look at the frame NUMBER with that last patch of mine. The frame NUMBER is could easily be wrong when recording. I will take a look at that tomorrow. |
| [06:11:10] | taylorr: | with the latest ffmpeg the processed frame now contains all the information from the packet |
| [06:11:27] | taylorr: | jpabq: the frame numbers look ok for the recorder :) |
| [06:11:33] | taylorr: | it's wrong for mythcommflag |
| [06:11:44] | jpabq: | stichnot: are you running master, and therefore the latest ffmpeg sync? |
| [06:12:08] | jpabq: | taylorr: I bet it is off by one, one subsequent back-to-back recordings, though. |
| [06:12:33] | jpabq: | Actually no, it should be okay |
| [06:12:44] | taylorr: | jpabq: you need to be aware of the difference between decoded and presentation order for the frame numbers |
| [06:13:21] | jpabq: | Yeah, I understand the difference. In the recorder we don't care, we just count how many frames we have seen. |
| [06:13:36] | taylorr: | I imagine that the recorder can only track decoded order |
| [06:15:18] | jpabq: | At least with HD-PVR material, it looks like a "payload" starts in right place, even if the following frames need re-ordered to get in presentation order. |
| [06:16:34] | taylorr: | I believe the big issue with mythcommflag is that framesRead/framesPlayed get out-of-sync somehow.... if I could figure out how to get log output then I could make some progress |
| [06:17:23] | taylorr: | I think some of the code paths use "cout"... not sure if that's a problem or not |
| [06:18:05] | jpabq: | The "old" logger didn't care if cout was used, it still ended up in the log file. I don't know if the new logger code handles that, though. |
| [06:18:24] | taylorr: | jpabq: for the recorder the byte position is definitely off for the keyframe |
| [06:19:05] | jpabq: | In what way? The byte position the records, is the byte position of the start of the "payload". |
| [06:19:42] | jpabq: | The byte position that the recorder, records, is the byte position of the payload. |
| [06:20:31] | taylorr: | they are all 188-bytes at least |
| [06:22:49] | jpabq: | Should all be a multiple of 188, since a payload will always start a new packet. Are they not divisible by 188? |
| [06:22:55] | taylorr: | jpabq: compared to the mythcommflag and ffmpeg the recorders byte positions are a little less |
| [06:23:11] | taylorr: | yes they are all 188-byte multiples |
| [06:23:42] | taylorr: | seems that the delta varies a little bit |
| [06:25:29] | jpabq: | I have no idea what ffmpeg is keying off of to get such an offset. |
| [06:25:48] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Remote host closed the connection) | |
| [06:25:48] | taylorr: | jpabq: sometimes the recorders byte count is correct sometimes it's upto about 8 packets less |
| [06:26:17] | taylorr: | jpabq: it's possible the recorder is correct |
| [06:26:59] | taylorr: | I have performed several cuts based on ffmpeg numbers and not had any issues to note |
| [06:27:24] | taylorr: | but I might have the same results with the recorder marks too if I tried |
| [06:27:39] | jpabq: | The recorder offsets are LESS than ffmpeg/commflag? In that case, I bet it is because the recorder will include audio packets that show up before the video packets. |
| [06:28:17] | taylorr: | jpabq: yes, the recorder is less |
| [06:28:40] | taylorr: | I could make some cuts and then see if they are audio packets |
| [06:28:48] | taylorr: | easy to test |
| [06:38:52] | taylorr: | jpabq: ok, looks like the recorder sometimes has a few audio packets in front of the first video packet at the keyframe mark |
| [06:39:23] | taylorr: | so I believe ffmpeg is more exact but the recorder should be fine too |
| [06:39:33] | jpabq: | Right from the get-go, the HD-PVR spits out audio packets in front of video packets. |
| [06:39:58] | taylorr: | of course it would be nice if they matched which would make stichnot happy |
| [06:40:00] | jpabq: | As soon as we tell the HD-PVR to "start encoding", we always get audio packets first. |
| [06:41:05] | taylorr: | ok, so one mystery solved |
| [06:41:27] | taylorr: | the other issue is that the frame numbers are off for mythcommflag (correct for the recorder) |
| [06:41:48] | taylorr: | time for sleep |
| [06:42:41] | jpabq: | Me too. Good night. |
| [06:54:56] | SteveGoodey (SteveGoodey!~steve@host86-147-183-135.range86-147.btcentralplus.com) has joined #mythtv | |
| [06:56:18] | Goga777 (Goga777!~Goga777@95-30-39-31.broadband.corbina.ru) has joined #mythtv | |
| [07:02:10] | SteveGoodey (SteveGoodey!~steve@host86-147-183-135.range86-147.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [08:00:14] | FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has joined #mythtv | |
| [08:22:07] | bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has joined #mythtv | |
| [08:22:32] | aloril (aloril!~aloril@dsl-tkubrasgw3-54f97e-153.dhcp.inet.fi) has quit (Ping timeout: 276 seconds) | |
| [08:34:56] | aloril (aloril!~aloril@dsl-tkubrasgw3-54f97e-153.dhcp.inet.fi) has joined #mythtv | |
| [08:35:43] | Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:e49d:9110:78b1:bae0) has joined #mythtv | |
| [09:25:35] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_) | |
| [09:27:08] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [09:42:02] | Goga777 (Goga777!~Goga777@95-30-39-31.broadband.corbina.ru) has quit (Ping timeout: 252 seconds) | |
| [09:54:49] | Goga777 (Goga777!~Goga777@128-71-94-179.broadband.corbina.ru) has joined #mythtv | |
| [09:54:50] | FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has quit (Quit: FabriceMG) | |
| [10:27:54] | Goga777 (Goga777!~Goga777@128-71-94-179.broadband.corbina.ru) has quit (Remote host closed the connection) | |
| [10:31:00] | jya_: | Seeker`: have you opened a bug for the RAOP stuff? |
| [10:40:29] | Seeker`: | jya_: I didn't open it, but there was one |
| [10:40:39] | Seeker`: | err |
| [10:40:41] | Seeker`: | wait |
| [10:40:42] | Seeker`: | not |
| [10:40:43] | Seeker`: | *no |
| [10:40:44] | jya_: | got a lik? |
| [10:40:47] | jya_: | link |
| [10:41:02] | jya_: | otherwise that's fine, i'll open one' |
| [10:41:03] | Seeker`: | Bug was only for the interactive TV stuff |
| [10:41:23] | jya_: | tbh, why should I be the one renaming my class, when it's been there for much longer than the new one ? |
| [10:41:34] | Seeker`: | I think that patch might also fix this bug: http://code.mythtv.org/trac/ticket/11190 |
| [10:41:41] | jya_: | I vote for renaming the other class everywhere |
| [10:41:47] | Seeker`: | Feel free :P |
| [10:44:00] | jya_: | can you reproduce the issue on 11190? |
| [10:44:28] | Seeker`: | I was the one that provided the "better backtraces in IRC" 2 months ago |
| [10:44:46] | Seeker`: | I'm going to try reverting that diff tonight and see if the crash comes back |
| [10:45:44] | bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has quit (Quit: Ex-Chat) | |
| [10:47:38] | alan` (alan`!alan@abacus.kwzs.be) has joined #mythtv | |
| [10:48:42] | jya_: | i'll commit something soon… If you could test it and update the bug accordingly, that would be appreciated |
| [10:51:34] | Seeker`: | jya_: I've got the unpatched version rebuilding now. I'll be able to test it at lunchtime ( just under 2 hours or so) |
| [10:51:43] | jya_: | ok |
| [10:55:14] | jya_: | I get segfault with master almost all the time these days... |
| [10:58:14] | Seeker`: | doing anything in particular? |
| [11:03:02] | jya_: | always in the SSDP thread |
| [11:03:20] | jya_: | 0.26 starts well… haven't spent much time trying master |
| [11:04:56] | stuartm: | jya_: I'm not arguing with renaming the MHEG class, but that patch was a good year older than the ROAP code |
| [11:05:22] | jya_: | stuartm: I was referring to the NetStream class :) |
| [11:07:14] | stuartm: | jya_: so was I, the NetStream class was added to support online content/videos with mheg, LVR wrote it ages ago and it sat for months in trac waiting for people to sign off (and when I couldn't convince anyone else to do that I just committed it) |
| [11:07:46] | jya_: | interesting… then even more surprising that the issue is in master only... |
| [11:07:49] | jya_: | wonder why that is |
| [11:07:54] | stuartm: | but it's entirely my fault, I should have checked that no class name collisions had been introduced in the mean time |
| [11:08:24] | stuartm: | jya_: it was only committed after the 0.26 release, but the work was done long before |
| [11:08:36] | jya_: | that makes sense |
| [11:08:43] | jya_: | was that back ported to 0.26? |
| [11:08:54] | jya_: | in any case, if it wasn't pushed/committed, it doesn't count :) |
| [11:09:01] | stuartm: | er, don't believe so |
| [11:09:24] | jya_: | ok.. so i don't need to back port the rename of the class to 0.26? |
| [11:09:31] | stuartm: | no |
| [11:10:51] | jya_: | what I also don't understand is that I'm fairly curtained I had compilation issue at some stage and I renamed the RAOP NetStream... |
| [11:10:58] | jya_: | wonder where those changes went |
| [11:11:41] | stuartm: | jya_: well that's the really weird bit, I could have sworn it had been renamed already |
| [11:12:06] | jya_: | ah, so I'm not dreaming it... |
| [11:13:10] | stuartm: | I thought I might be the one dreaming it :) No, I remember clearly it being talked about and I thought I remembered a commit, but ... |
| [11:15:13] | jya_: | could have only done it locally.. I remember warnings in cppcheck and the other external static analyser (can't remember the name) |
| [11:25:07] | Seeker`: | stuartm: do you have airplay disabled at the moment? |
| [11:27:06] | Seeker`: | if that renaming does fix the MHEG stuff, I wonder why it wasn't apparent on your system |
| [11:27:59] | jya_: | Seeker`: doesn't matter if it's loaded or not really... |
| [11:28:22] | jya_: | the library are there, you can't ever be certain which one is going to be loaded |
| [11:28:23] | stuartm: | Seeker`: I've not explicitly disabled it, but I've never used it so it if it's disabled by default or requires dependencies missing on my system then that could explain it |
| [11:28:48] | stuartm: | I don't own any Apple devices |
| [11:28:49] | Seeker`: | jya_: Yeah. Just trying to work out why a few people got the bug and not others |
| [11:29:11] | jya_: | could simply due to the path of their machine etc…. |
| [11:29:40] | stuartm: | Seeker`: different versions of ld or different lib paths, it happens more often than you might think |
| [11:30:17] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Read error: Connection reset by peer) | |
| [11:30:22] | jya__ (jya__!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [11:30:25] | jya__ (jya__!~jyavenard@mythtv/developer/jya) has quit (Read error: Connection reset by peer) | |
| [11:30:42] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [11:45:21] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_) | |
| [11:54:35] | bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has joined #mythtv | |
| [12:34:18] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [12:47:09] | Seeker`: | jya_: Reverting my patch makes MHEG crash again, so it does look like it fixes #11190 |
| [12:47:09] | ** MythLogBot http://code.mythtv.org/trac/ticket/11190 ** | |
| [12:48:39] | Goga777 (Goga777!~Goga777@128-71-94-179.broadband.corbina.ru) has joined #mythtv | |
| [13:02:11] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv | |
| [13:26:03] | Kevin` is now known as Kevin`_ | |
| [13:30:18] | Kevin` (Kevin`!~kevin@router.kwzs.be) has joined #mythtv | |
| [13:40:34] | Kevin`_ (Kevin`_!~kevin@etmalec.net) has quit (Quit: leaving) | |
| [13:56:46] | stichnot: | taylorr, jpabq: sorry for disappearing last night. It's an annoying mystery to me why mythcommflag doesn't honor the logging options. As for the seektable discrepancy, I'm not so concerned about the file position of the keyframes, since ffmpeg seems to deal with that during playback and cutting/transcoding. It's the keyframe number drift that's the problem. This will make bookmarks and... |
| [13:56:48] | stichnot: | ...cutlists wrong after regenerating the seektable, and possibly introduce corruption for people who use scripts to cut the file at keyframe boundaries. |
| [14:42:22] | Goga777 (Goga777!~Goga777@128-71-94-179.broadband.corbina.ru) has quit (Read error: Connection reset by peer) | |
| [14:43:32] | Goga777 (Goga777!~Goga777@128-71-94-179.broadband.corbina.ru) has joined #mythtv | |
| [14:54:31] | danielk22 (danielk22!~danielk@exchange.wgen.net) has joined #mythtv | |
| [15:12:01] | taylorr: | Captain_Murdoch: ^^^ any idea why mythcommflag doesn't output logging when running with -v options? |
| [15:16:35] | danielk22: | taylorr: You probably didn't set the error level high enough. |
| [15:17:31] | ** stuarta has to work out why the dev backend isn't logging anything! ** | |
| [15:17:52] | stuarta: | i suspect it's got something to do with the prod backend already running a log server |
| [15:24:22] | tgm4883 (tgm4883!~tgm4883@ubuntu/member/tgm4883) has quit (Quit: ZNC - http://znc.in) | |
| [15:24:55] | tgm4883 (tgm4883!~tgm4883@ubuntu/member/tgm4883) has joined #mythtv | |
| [15:29:54] | taylorr: | danielk22: I set --loglevel debug |
| [15:30:30] | danielk22: | "-v general" as well? |
| [15:30:43] | danielk22: | those to should be sufficient to see some logging |
| [15:30:52] | danielk22: | s/to/two/ |
| [15:31:05] | taylorr: | nope, even tried -v all |
| [15:32:32] | danielk22: | :| |
| [15:32:50] | danielk22: | I think the new logging is too complex + buggy :| |
| [15:33:59] | danielk22: | (This may very well not be the logging but the command line parsing, but the sentiment remains) |
| [15:37:05] | stuarta: | still a few rough edges here and there |
| [15:37:17] | ** stuarta wants to pull it apart and tweak it ** | |
| [15:45:01] | stichnot: | The thing I miss most in logging is --logfile . |
| [15:46:40] | stuarta: | i like to be able to use logrotate and always look at mythbackend.log |
| [15:46:47] | dekarl: | Hmm, is it just me or does a master MBE really need two kills to end? Sometimes I forget the manual second kill when upgrading to a new package :/ |
| [15:47:42] | stuarta: | at least i've just proved something, if 0.26 is already running (& thus it's logserver is too), when firing up a git backend it connects to the 0.26 logger to log |
| [15:47:46] | stuarta: | doh! |
| [15:51:54] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Read error: Operation timed out) | |
| [15:54:31] | jams: | dekarl, your not the first to mention it |
| [15:58:21] | stuartm: | dekarl: it's not that it takes two, the first causes the backend to shutdown cleanly and that can take a few seconds |
| [15:58:39] | stuartm: | well maybe more than a few |
| [15:58:50] | stuartm: | we need something in the logs to indicate what is happening |
| [15:59:25] | stuartm: | a second kill signal while we're shutting down will exit immediately (but not cleanly) |
| [15:59:41] | stuarta: | yes it does take ages to shutdown |
| [15:59:52] | stuartm: | what really needs fixing is the time it takes to shutdown |
| [15:59:58] | stuarta: | +1 |
| [16:00:14] | stuartm: | it's unreasonably and inexplicably slow |
| [16:15:51] | dekarl: | hmm, I wonder if we can tell the upstart script to wait for the process to end before continuing/restarting it |
| [16:16:35] | Goga777 (Goga777!~Goga777@128-71-94-179.broadband.corbina.ru) has quit (Read error: No route to host) | |
| [16:17:33] | Goga777 (Goga777!~Goga777@128-71-94-179.broadband.corbina.ru) has joined #mythtv | |
| [16:19:03] | Goga777 (Goga777!~Goga777@128-71-94-179.broadband.corbina.ru) has quit (Read error: Connection reset by peer) | |
| [16:19:47] | Goga777 (Goga777!~Goga777@128-71-94-179.broadband.corbina.ru) has joined #mythtv | |
| [16:21:17] | Goga777 (Goga777!~Goga777@128-71-94-179.broadband.corbina.ru) has quit (Read error: No route to host) | |
| [16:22:00] | Goga777 (Goga777!~Goga777@128-71-94-179.broadband.corbina.ru) has joined #mythtv | |
| [16:34:56] | stichnot (stichnot!~stichnot@67.218.110.93) has joined #mythtv | |
| [16:34:56] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [16:34:56] | stichnot (stichnot!~stichnot@67.218.110.93) has quit (Changing host) | |
| [16:38:18] | stichnot: | stuartm: On my production system, I've never ever witnessed the backend shutting down after a single kill. How long do you think one should wait for a clean shutdown? |
| [16:38:40] | stichnot: | (and I mean how long with the current code, not a in a perfect world) |
| [16:46:01] | stuartm: | heh, just tried it and it's not exiting ... last thing in the logs is "mythbackend[22746]: N CoreContext main_helpers.cpp:680 (run_backend) MythBackend exiting" |
| [16:46:19] | stuartm: | so it's clearly been broken :( |
| [16:54:44] | Merlin83b2 (Merlin83b2!~Daniel@office.34sp.com) has joined #mythtv | |
| [16:55:14] | Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:e49d:9110:78b1:bae0) has quit (Read error: Connection reset by peer) | |
| [17:00:08] | Goga777 (Goga777!~Goga777@128-71-94-179.broadband.corbina.ru) has quit (Remote host closed the connection) | |
| [17:03:43] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 252 seconds) | |
| [17:26:57] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [17:34:52] | slipcon (slipcon!~sjlipco@pool-70-110-28-70.washdc.fios.verizon.net) has joined #mythtv | |
| [17:39:02] | peper03 (peper03!~richard@port-92-203-0-142.dynamic.qsc.de) has joined #mythtv | |
| [17:49:16] | Mousey (Mousey!~r0dent_@ross154.net) has joined #mythtv | |
| [17:55:41] | Captain_Murdoch: | taylorr, not sure on the logging issue. haven't been in there since the logging was changed and haven't done any flagging accuracy debugging in quite a while. |
| [17:58:22] | Captain_Murdoch: | might require a special flag. I had some things in there that would print to stdout for really verbose debugging and I think some of that may have been reworked as part of the logging changes. |
| [17:58:55] | Captain_Murdoch: | nothing looks out of the ordinary glancing at the code, but I have a meeting to go to and can't look deeper. |
| [18:01:59] | Mousey (Mousey!~r0dent_@ross154.net) has left #mythtv ("Leaving") | |
| [18:08:02] | taylorr: | Captain_Murdoch: thanks for looking |
| [18:10:34] | dekarl (dekarl!~dekarl@p4FCEF076.dip.t-dialin.net) has quit (Ping timeout: 256 seconds) | |
| [18:13:20] | dekarl (dekarl!~dekarl@p4FCEF8F0.dip.t-dialin.net) has joined #mythtv | |
| [18:20:44] | bill6502 (bill6502!~bill@2002:cdb2:1a2b:7cd3:9ef4:32ea:c6ea:200) has joined #mythtv | |
| [18:23:20] | IReboot (IReboot!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has joined #mythtv | |
| [18:25:06] | bill6502: | ^^^ buntu workaround for multi-kill issue, assumes using: sudo stop mythtv-backend for the initial stop. http://paste.ubuntu.com/1659151/ (add to the bottom of /etc/init/mythtv-backend.conf) |
| [18:25:15] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [18:27:49] | stoffel (stoffel!~quassel@pD9E43CE1.dip.t-dialin.net) has joined #mythtv | |
| [18:36:21] | bill6502 (bill6502!~bill@2002:cdb2:1a2b:7cd3:9ef4:32ea:c6ea:200) has left #mythtv () | |
| [18:48:44] | Merlin83b2 (Merlin83b2!~Daniel@office.34sp.com) has quit (Read error: Connection reset by peer) | |
| [18:49:11] | SteveGoodey (SteveGoodey!~steve@host86-147-183-135.range86-147.btcentralplus.com) has joined #mythtv | |
| [18:53:12] | SteveGoodey (SteveGoodey!~steve@host86-147-183-135.range86-147.btcentralplus.com) has quit (Client Quit) | |
| [19:09:10] | stichnot: | bill6502: thanks for that, I'm going to give it a try. |
| [19:10:31] | natanojl_ (natanojl_!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [19:10:33] | taylorr: | stichnot: being unable to get logging but I'm guessing the issue may be related to the H264Parser and detecting "onframe" and incrementing framesRead |
| [19:11:13] | taylorr: | wonder if there are any differences between the parser used in the recorder and the one used by the player |
| [19:11:57] | taylorr: | jpabq: ^^^ do you know if the parsers have any code differences between recorder and player? |
| [19:12:00] | stichnot: | taylorr: yeah, the logging problem frustrates me too. I will try looking deeper. As for the H264Parser, are you suggesting that the recorder is incrementing incorrectly? |
| [19:12:45] | stichnot: | There is certainly the issue that the hdpvr recorder sets the IDR flag of the parser whereas the player normally does not |
| [19:15:59] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Ping timeout: 260 seconds) | |
| [19:17:32] | jpabq: | taylorr: stichnot, I have become very intimate with the recorder ;-) But know very little about playback or comm flagging at this time. |
| [19:25:09] | taylorr: | jpabq: I was just wondering if the H264Parser is shared amongst recorder and playback |
| [19:26:10] | taylorr: | stichnot: No, the recorder is fine... there should be an H264Parser in the player code too which I think is what mythcommflag would use |
| [19:27:06] | taylorr: | stichnot: if they are identifying IDR differently then that might be your issue |
| [19:27:21] | taylorr: | if we made changes to the recorder by not the player then that would be an issue |
| [19:29:59] | jpabq: | It should not be hard to make "mythcommflag --rebuild" and the recorder use a common class for identifying keyframes. It would be a bit of a specialized case for mythcommflag, though, since it would no longer use ffmpeg "decoding" to find them. |
| [19:30:25] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [19:32:56] | kwmonroe (kwmonroe!~kwmonroe@32.97.110.60) has quit (Ping timeout: 245 seconds) | |
| [19:33:32] | jpabq_ (jpabq_!~quassel@mythtv/developer/jpabq) has quit (Disconnected by services) | |
| [19:34:50] | jpabq_ (jpabq_!~quassel@mythtv/developer/jpabq) has joined #mythtv | |
| [19:41:20] | stichnot: | taylorr: yes, both the recorder and the player share the H264Parser class. |
| [19:41:25] | jpabq_ (jpabq_!~quassel@mythtv/developer/jpabq) has quit (Disconnected by services) | |
| [19:42:45] | jpabq_ (jpabq_!~quassel@mythtv/developer/jpabq) has joined #mythtv | |
| [19:43:25] | stichnot: | taylorr: the IDR issue was reported and dealt with in #11144 . |
| [19:43:25] | ** MythLogBot http://code.mythtv.org/trac/ticket/11144 ** | |
| [19:44:16] | stichnot: | originally mythcommflag produced keyframes every 32 frames or something like that, which was completely bogus |
| [19:45:01] | stichnot: | now mythcommflag and the recorder identify the same number of keyframes, but the frame numbers drift |
| [19:47:21] | kwmonroe (kwmonroe!~kwmonroe@32.97.110.60) has joined #mythtv | |
| [19:47:21] | MaStr-- (MaStr--!~Matthias@freeshell.de) has joined #mythtv | |
| [19:47:45] | stichnot: | So you determined that the recorder's frame number is the correct one? I haven't known in the past which code path to try to debug. |
| [19:47:57] | MaStr-- (MaStr--!~Matthias@freeshell.de) has left #mythtv () | |
| [19:48:48] | stichnot: | I would be more inclined to believe that the HDPVR has a consistent keyframe distance, and the recorder always has a keyframe distance of 128 |
| [20:25:01] | stoffel (stoffel!~quassel@pD9E43CE1.dip.t-dialin.net) has quit (Ping timeout: 245 seconds) | |
| [20:35:57] | bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has quit (Quit: Leaving) | |
| [20:41:30] | Steve_Goodey (Steve_Goodey!~steve@host86-147-183-135.range86-147.btcentralplus.com) has joined #mythtv | |
| [21:00:40] | rsiebert_ (rsiebert_!~quassel@g225061005.adsl.alicedsl.de) has joined #mythtv | |
| [21:03:47] | rsiebert (rsiebert!~quassel@g225051002.adsl.alicedsl.de) has quit (Ping timeout: 260 seconds) | |
| [21:24:14] | skd5aner: | I just wanted to throw out I mentioned the "two kill" thing a long time ago and people thought I was crazy... |
| [21:25:10] | skd5aner: | glad to hear others are seeing it, but why in the world was I easily dismissed – I bet I couldn't have been the only one seeing it at the time |
| [21:25:30] | skd5aner: | that said... I also see it with mythfrotnend, so it's not just a backend only thing |
| [21:25:45] | skd5aner: | I have to do a killall mythfrontend twice when the frontend hangs |
| [21:27:11] | wagnerrp: | two kill? |
| [21:27:48] | wagnerrp: | oh, because the signal handler catches the first kill and tries to close things cleanly |
| [21:30:16] | stichnot: | I find that the frontend almost always responds to the single kill, unless it gets "very" wedged. The backend is a different story, and for some reason always requires two kills. |
| [21:32:58] | peper03: | FWIW, the times when I have to kill the frontend, I don't ever remember it terminating after only one kill. I'm fairly sure it's the same for MythWelcome (I don't think it gets wedged but when I wanted to stop it) |
| [21:34:21] | tgm4883: | When asking the backend to stop (via SIGTERM), how long is appropriate to wait before sending SIGKILL? |
| [21:38:10] | kwmonroe (kwmonroe!~kwmonroe@32.97.110.60) has quit (Quit: Coyote finally caught me) | |
| [21:58:22] | dekarl: | bill6502, stichnot, http://paste.ubuntu.com/1659781/ should do basically the same |
| [21:59:53] | dekarl: | but it enforces the kill -9 after 5 seconds which is why we're wondering how long it takes to shutdown normally for everyone |
| [22:05:00] | skd5aner: | well, if you look in the backlog, stuartm mentioned that it appears to be broken – so there currently is no "normal" :) |
| [22:06:20] | peper03: | Why on earth does ffmpeg only return half an audio frame when I stop providing it with new data, even though it already has the other half in its buffers somewhere?! |
| [22:07:53] | peper03: | And both halves were passed in in one go anyway. |
| [22:08:07] | dekarl: | skd5aner: but how long is enough to not make things worse |
| [22:09:00] | skd5aner: | :) |
| [22:13:52] | peper03: | Really starting to get fed up trying to work round ffmpeg actively filtering packets. I can understand why xine went the route of parsing the MPEG stream themselves, but I *really* don't want to go there as it looks like a world of pain (now and in the future). |
| [22:14:40] | peper03: | ffmpeg irc and mailing lists are also deathly quiet on how it should be done (or why it is the way it is). |
| [22:15:11] | tgm4883: | dekarl, if we don't get someone to comment on that timeout in the next 60 minutes, go ahead and push the change as it. That way we can get it in tonights builds |
| [22:15:26] | tgm4883: | builds happen in about 2 hours |
| [22:16:05] | stichnot: | peper03: I take it that means the upcoming ffmpeg 1.1 resync won't help us there? |
| [22:18:18] | slipcon (slipcon!~sjlipco@pool-70-110-28-70.washdc.fios.verizon.net) has quit (Quit: Leaving.) | |
| [22:19:06] | peper03: | stichnot: I have no idea but I doubt it somehow. It's incredibly frustrating spending days trying to find a way to implement something that will always be hack when you can see how (probably) a few changes could solve the problem cleanly but it's not part of Myth and no-one seems to be able to offer any help. |
| [22:19:17] | peper03: | Even beer isn't helping :( |
| [22:21:11] | Steve_Goodey (Steve_Goodey!~steve@host86-147-183-135.range86-147.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [22:24:16] | peper03: | stichnot: Just checked, nope. The stuff we need is still being filtered: http://git.videolan.org/?p=ffmpeg.git;a=blob; . . . hb=HEAD#l249 |
| [22:26:02] | peper03: | Maybe I'm missing something really obvious but I don't see what advantage is gained by not passing data on to the user and letting them decide whether they're interested in it or not. |
| [22:28:54] | stichnot: | kenni: regarding #10222. I've been running with that patch for several days and so far no commflag jobs have segfaulted. Usually I'd get a couple by now. I was planning on committing it in a week if it holds up. |
| [22:28:54] | ** MythLogBot http://code.mythtv.org/trac/ticket/10222 ** | |
| [22:31:39] | kenni (kenni!~kenni@mythtv/developer/kenni) has joined #mythtv | |
| [22:32:15] | kenni: | stichnot: Good to hear, thanks. |
| [22:34:31] | stoffel (stoffel!~quassel@pD9E43CE1.dip.t-dialin.net) has joined #mythtv | |
| [22:35:28] | stichnot: | peper03: Is it possible to write a small patch that doesn't impact CPU or memory performance in the common case, that might be accepted by ffmpeg? |
| [22:39:12] | peper03: | stichnot: Possibly. I don't really understand how the ffmpeg architecture works but just looking at that file, I would guess that you'd need to define a codec ID to identify the 'new' packets. That shouldn't be a big issue but I don't know whether it's necessary to also decode the contents of the packet in some way. |
| [22:41:03] | peper03: | I'll have to look at what other data packets can be returned and see how it's done there. For my purposes, I can live with raw data but that I could imagine that wouldn't be the preferred method for a potential patch. |
| [22:42:54] | peper03: | The fact that these packets are being explicitly ignored bothers me a bit but maybe it's just because nobody wanted to write support for them but they need to be handled in some way (i.e. skipped) to allow following packets to be handled. |
| [22:47:24] | danielk22 (danielk22!~danielk@exchange.wgen.net) has left #mythtv () | |
| [22:54:22] | kwmonroe (kwmonroe!~kwmonroe@32.97.110.60) has joined #mythtv | |
| [22:55:27] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit (Quit: http://www.youtube.com/watch?feature=player_embedded&v=VTV23B5gBsQ#!) | |
| [23:03:00] | stoffel (stoffel!~quassel@pD9E43CE1.dip.t-dialin.net) has quit (Remote host closed the connection) | |
| [23:13:30] | kwmonroe (kwmonroe!~kwmonroe@32.97.110.60) has quit (Quit: Coyote finally caught me) | |
| [23:14:36] | gregL_ (gregL_!~greg@cpe-74-76-105-205.nycap.res.rr.com) has quit (Quit: Leaving) | |
| [23:23:01] | mad_enz (mad_enz!~Enz@dsl-173-206-174-151.tor.primus.ca) has joined #mythtv | |
| [23:48:07] | Tobbe5178 (Tobbe5178!~asdf@h186n5-sv-a13.ias.bredband.telia.com) has quit (Read error: Connection reset by peer) | |
| [23:48:48] | taylorr: | stichnot: sorry, went away for a while... yes, according to ffmpeg the frame numbers match the recorders seektable |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.