| Wednesday, July 24th, 2013, 16:55 UTC | ||
| [16:55:52] | peper03: | Hmm. AvFormatDecoder::SeekReset empties 'storedPackets' if the 'doflush' parameter is true. AvFormatDecoder::Reset will do that indirectly iff the 'seek_reset' parameter is true, but not if the 'reset_video_data' parameter is true. Is that right? And since Reset gets called from the player thread, should storedPackets not be protected by a semaphore? |
| [17:01:30] | bobweaver: | Looking better ? http://imagebin.org/265494 |
| [17:02:47] | jheizer (jheizer!~jheizer@c-98-226-220-178.hsd1.il.comcast.net) has joined #mythtv | |
| [17:43:38] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [17:49:31] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 260 seconds) | |
| [17:51:05] | SteveGoodey (SteveGoodey!~steve@host86-160-206-25.range86-160.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [18:20:57] | peper03: | jya: If I skip between chapters quickly on a DVD, I can sometimes cause a segfault. Not sure if it's always at the same place, but certainly in ffmpeg code. At the moment, it's in av_parser_parse2. The AVStream passed in (from parse_packet) has the parser field set to NULL. AVFormatContext.nb_streams is set to 7 but all of the streams have a NULL parser. Any ideas? |
| [18:27:21] | peper03: | And twice now in ff_thread_report_progress from (indirectly) mpeg_decode_slice. The AVFrame passed in is NULL. |
| [18:38:58] | peper03: | Yep, nearly always in ff_thread_report_progress. And only with OpenGL rendering. Can't reproduce it with VDPAU. |
| [18:51:32] | peper03: | And another while calling AvFormatDecoder::SeekReset from the player thread: http://pastebin.com/FG1d7MU9 |
| [18:52:19] | peper03: | ff_read_frame_flush in that backtrace loops through all the parsers, closing them and setting them to NULL. So that ties in with the segfault in av_parser_parse2. |
| [18:54:27] | peper03: | So that looks like an interesting problem to solve. How to synchronise not only the player and decoder threads but also worker threads created by ffmpeg? |
| [18:54:56] | peper03: | danielk22: ^^ |
| [19:09:45] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 264 seconds) | |
| [19:13:30] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [19:22:57] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [19:25:00] | bobweaver: | ok well I can not paste for somereason WTF is going on here sorry matt |
| [19:25:07] | bobweaver: | er wrong channel |
| [19:28:22] | bobweaver: | Can any of you see anything wrong with this ? http://pastebin.com/D1ih8hhL |
| [19:28:41] | bobweaver: | it will not load mysql driver no matter what I have tried |
| [19:41:05] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 261 seconds) | |
| [19:58:51] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [20:01:06] | gigem: | I figured the channel rule change would create a firestorm when the masses found out. I'm amazed, though, at how many have such strong opinions without trying it first or really knowing what changed. |
| [20:03:10] | jheizer_: | but but but IT CHANGED! :banghead: Some people just like to complain. |
| [20:10:21] | stuartm: | of those complaining I'd bet many don't even use channel rules or aren't aware just how fragile channel rules are |
| [20:12:56] | stuartm: | in the UK they are next to useless, channels move around all the time and we now have many +1 channels (1 hour timeshifts of various channels) where using a single channel rule would risk unnecessary conflicts |
| [20:16:51] | stichnot: | peper03: mythcommflag --rebuild for audio-only recordings is going to be harder than I thought. It seems that DTVRecorder::FindAudioKeyframes() actually uses wall-clock time to decide when a "keyframe" is seen, where a keyframe is actually defined as every 8th "frame", and the framerate is either 25fps or 29.97fps depending on the value of the "tvformat" setting. |
| [20:21:39] | stichnot: | danielk22: That was your commit from only 6 years ago, so I'm sure the details are still fresh in your mind, in case you have any insights :) |
| [20:22:58] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit (Quit: i enjoy epicaricacy. (made you look it up)) | |
| [20:23:38] | peper03: | stichnot: Is the problem getting the 'keyframes' to match what would have been generated? If so, does that matter? I think I don't quite understand the problem (but looking at the code, I don't quite understand that either :) ) |
| [20:25:02] | peper03: | I see the stuff with msec_per_day and expected_frame etc. but I haven't analysed it enough to understand the exact logic in there. |
| [20:31:31] | peper03: | Ah, it's *really* using elapsed wall-clock time from _audio_timer, right? So it currently only works in realtime. |
| [20:32:57] | stichnot: | The problem is that MythCommFlagPlayer (or basically MythPlayer) just won't be able to reproduce the same keyframe positions or durations as the recorder. And to make mythcommflag produce anything meaningful, it needs a different way of iterating over frames. |
| [20:34:03] | stichnot: | I wonder if DTVRecorder::FindAudioKeyframes() could use pts/dts information from the audio packets. But that's not for 0.27 |
| [20:36:11] | Jim_Lahey (Jim_Lahey!~bobweaver@173-86-137-131.dsl1-field.roch.ny.frontiernet.net) has joined #mythtv | |
| [20:36:35] | Jim_Lahey is now known as Guest49357 | |
| [20:37:09] | Guest49357 (Guest49357!~bobweaver@173-86-137-131.dsl1-field.roch.ny.frontiernet.net) has quit (Client Quit) | |
| [20:37:46] | peper03: | stichnot: For my purposes, I don't need to be able to rebuild the seektable. I quite often put the 'radio' on via LiveTV at the weekend and occasionally skip back if the kids talk (or argue :) ) just as I wanted to hear something, but that's about my use case. For completeness though, it would be good to be able to rebuild the seektables. |
| [20:38:09] | peper03: | s/about/about it for/ |
| [20:38:29] | bobweaver (bobweaver!~bobweaver@ubuntu/member/bobweaver) has quit (Ping timeout: 248 seconds) | |
| [20:38:42] | peper03: | Whether that comes for 0.27 or later, doesn't bother me too much :) |
| [20:39:52] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 260 seconds) | |
| [20:46:06] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [21:07:15] | len (len!~quassel@75-168-36-94.mpls.qwest.net) has joined #mythtv | |
| [21:32:22] | Chutt (Chutt!~ijr@cpe-76-190-199-73.neo.res.rr.com) has quit (Read error: Connection reset by peer) | |
| [21:40:25] | jheizer_ (jheizer_!~jon@c-98-226-220-178.hsd1.il.comcast.net) has quit (Quit: Leaving) | |
| [21:43:02] | Chutt (Chutt!~ijr@cpe-76-190-199-73.neo.res.rr.com) has joined #mythtv | |
| [21:56:21] | skd5aner: | gigem: I'm indifferent because I haven't tried it... but what was the purpose behind making the channel rule a filter rather than a rule? |
| [22:00:13] | Chutt (Chutt!~ijr@cpe-76-190-199-73.neo.res.rr.com) has quit (Read error: Connection reset by peer) | |
| [22:12:34] | gigem: | skd5aner: To simplify the schedule editor by offering fewer rule types on the main page. How often does someone really change the type of an existing rule? I don't know about MCE some other cable DVRs, but I do know TiVo and FIOS' DVR don't even allow the rule type to be changed. |
| [22:13:17] | skd5aner: | gotcha... although, I would say for the longest time the vast majority of my rules were channel rules |
| [22:13:47] | skd5aner: | primarily because of HD vs SD |
| [22:14:13] | skd5aner: | but now, data is so good from Schedules Direct, that I can just use an "HD" filter on an Any Channel rule |
| [22:19:37] | dekarl1: | skd5aner: just disable the SD variant... If you're a transcoder you want the best source quality, if you're a watch'n'deleter it doesn't matter either. |
| [22:19:54] | dekarl1 is now known as dekarl | |
| [22:20:50] | skd5aner: | dekarl: I've kept SD around forever because it's SIGNIFICANTELY easier/faster to use for live tv. I have 1 STB/HD-PVR combo that get's 80% of my HD channels, and several QAM tuners that get my locals... so the SD tuners still play a role |
| [22:21:05] | skd5aner: | but, for scheduled recordings, I don't really care for them |
| [22:22:11] | ** dekarl needs to check if you can set the *recording* order to "do not use this card" ** | |
| [22:22:44] | skd5aner: | they are definitely my lowest priority cards, and I haven't decided if I want to take them completely out of the recording pool yet |
| [22:22:53] | skd5aner: | although, I think I'm finally to the point where I could |
| [22:23:01] | papertigers (papertigers!~papertige@pool-98-118-156-189.bflony.fios.verizon.net) has joined #mythtv | |
| [22:23:36] | dekarl: | Ahhh: "If set to "0", then the input is excluded from scheduled recordings (use for Live TV only)" from http://www.mythtv.org/wiki/Release_Notes_-_0.25#Scheduler |
| [22:23:41] | skd5aner: | dekarl: I think in 0.26 it was changed that you could set the priorit to 0 to take it out |
| [22:23:42] | papertigers (papertigers!~papertige@pool-98-118-156-189.bflony.fios.verizon.net) has quit (Client Quit) | |
| [22:24:03] | skd5aner: | ah, 0.25... but yea, I remembered that change |
| [22:25:00] | papertigers (papertigers!~papertige@pool-98-118-156-189.bflony.fios.verizon.net) has joined #mythtv | |
| [22:27:57] | stuartm: | skd5aner: one of the problems with 'channel' rules, especially when used to record HD over SD is that in reality few users want nothing to be recorded when it could have fallen back to the SD showing – that and other similar circumstances (say a programme is moved from one channel/network to another temporarily or permanently) mean that more often than not channel rules really aren't that great a solution vs adjusting channel/HD priorities |
| [22:28:45] | stuartm: | I wouldn't even use the HD filter personally, the HD priority option is much better |
| [22:31:50] | stuartm: | but more fundamentally, the channel rule stuff is imperfect because it references a channel based on data that can change following a rescan (chanid iirc), so all existing rules are periodically broken and need recreation |
| [22:35:07] | gigem: | stuartm: channel rules (and channel filter) use callsign/shortname so they are immune to chanid changes. Rescans can occasionally change the callsign, though, so users still need to be careful. |
| [22:47:24] | jr3us (jr3us!~jr3us2@cpe-098-026-209-039.triad.res.rr.com) has joined #mythtv | |
| [22:51:54] | jr3us: | greetings. I have been watching comments regarding the this channel setting and I am ok with how it works in mythfrontend . however it curently works differently in mythweb |
| [22:53:03] | jr3us: | when I learned the default could be change in default template , I was hopeful |
| [22:53:49] | skd5aner: | stuartm: isn't the HD priority option only something relative on custom rules? |
| [22:54:19] | jr3us: | mythweb though currently doesn't appear to pick up the settings for this channel from the default template |
| [22:54:22] | skd5aner: | stuartm: and yes, your example above is why I've almost eliminated all of my channel-only rules |
| [22:55:21] | Chutt (Chutt!~ijr@cpe-76-190-199-73.neo.res.rr.com) has joined #mythtv | |
| [22:55:34] | jr3us: | should I do a ticket for mythweb not picking up the setting? |
| [22:55:58] | skd5aner: | gigem: I'm not sure that's correct, but I definitely wouldn't argue with you on it... I used to have to rescan QAM channels frequently on a past provider – every time, I had to reset my channel rules when it switched channels – I'm almost certain that it always used to use chanid |
| [22:56:08] | skd5aner: | gigem: that migth have changed though |
| [22:56:51] | ** Captain_Murdoch does a quick query and notes that 94 of his 106 rules are channel rules, with the other 12 are any channel (of which 2 of the 12 are 'new show' power rules) ** | |
| [22:57:28] | stuartm: | skd5aner: no, it applies to all rules, Setup > Video > Recording Priorities > Set Recording Priorities |
| [22:58:20] | stuartm: | which incidently is a really stupid place to bury those settings |
| [22:59:06] | skd5aner: | maybe why I was unaware of it :) |
| [23:00:23] | jr3us: | the only rules i have that aren't channel specific are for for Star Trek :-) |
| [23:00:48] | jr3us: | and st next gen |
| [23:01:16] | Chutt (Chutt!~ijr@cpe-76-190-199-73.neo.res.rr.com) has quit (Read error: Connection reset by peer) | |
| [23:02:06] | gigem: | jr3us: Please open a ticket. Bare in mind we don't have any active mythweb developers right now, so there is no telling when it will get handled. The existing, minimal support for templates was contributed by a user. |
| [23:02:47] | papertigers (papertigers!~papertige@pool-98-118-156-189.bflony.fios.verizon.net) has quit (Quit: papertigers) | |
| [23:02:52] | kormoc: | gigem, isn't the backend taking over for myth web entirely for this release? Wasn't that the timeline? |
| [23:03:12] | gigem: | skd5aner: If you followed the recommendation to change your SD and HD channels to use the same callsign, you would probably have to fix the HD ones after rescans. |
| [23:04:01] | skd5aner: | kormoc: lol... pipedreams |
| [23:04:23] | skd5aner: | gigem: actually, ironically – I don't use the same callsigns |
| [23:04:49] | stuartm: | gigem: I was pretty sure it used to be chanid, although it makes little practical difference in the UK where names/callsigns do change all too frequently and are inconsistent between platforms (satellite vs OTA) |
| [23:04:50] | skd5aner: | gigem: but I know my channel rules were broke because after the rescan I'd get new channelIDs... |
| [23:04:50] | gigem: | kormoc: I don't remember. Personally, I don't pay much attention to grand visions, especially the ones from some former developers. Things will get done when there is someone motivated enough to get them done. |
| [23:05:16] | jr3us: | ok, thanks.will do, and understand. btw, I use mythweb most of the time for doing day to day stuff such as scheduling deleting , etc |
| [23:05:34] | gigem: | skd5aner: Nope, it's never used chanid. I don't know why your rules might have broken, then. |
| [23:06:03] | jr3us: | I hope mythweb sticks around. :-) |
| [23:06:16] | skd5aner: | gigem: hmmm, yea... I know you're the SME... so I definitely can't argue, I can just give you my user experience :) |
| [23:06:23] | kormoc: | gigem, well, there's no use for us to put time into myth web given it's just gonna get deleted soon :( |
| [23:06:59] | jr3us: | blahhst sad to hear that.. |
| [23:07:44] | skd5aner: | gigem: I always delete my source and channels (per sphery's advice) rescan, get new chanids, change the callsign and channum to what matches in Schedules Direct, add the TMSID, and then I would have to go in to my channel rule, change it to an any channel rule... |
| [23:07:52] | skd5aner: | ... and then change it back to a channel rule |
| [23:08:14] | gigem: | kormoc: Understood, but it's the definition of "soon" that is very debatable. :) |
| [23:08:24] | skd5aner: | needless to say, it's a classic example of why rescanning is the single most painful activity one can ever do with a MythTV setup... ever |
| [23:08:47] | skd5aner: | channel rules or not |
| [23:09:21] | skd5aner: | kormoc: yea... I think you have to be careful there... |
| [23:10:08] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 260 seconds) | |
| [23:10:09] | skd5aner: | kormoc: I know it's hard to put work in to something that is eventually destined for removal – but I think it's been about 3+ years since that idea was thrown around and the closest thing to it going away has only been the API creation |
| [23:10:21] | skd5aner: | could be another 3+ years |
| [23:11:01] | skd5aner: | Unless someone says they're going to replace it, and I havne't seen a single person volunteering to do so, I think mythweb will be around for a while |
| [23:11:18] | kormoc: | at one point there was a scheduled release to kill myth web in, and I stopped doing anything |
| [23:11:51] | gigem: | skd5aner: Rescanning is a pain for several reasons. |
| [23:11:59] | ** gigem is going afk for a while. ** | |
| [23:12:49] | stuartm: | jr3us: mythweb isn't really going anywhere, it was just going to change forms and be embedded into mythbackend so you wouldn't need to run a seperate webserver |
| [23:12:58] | skd5aner: | kormoc: that's where the mythtv project fails... no one is enforcing any roadmaps or strategies... someone can just suggest something, doesn't mean anyone will actually *do* it |
| [23:14:21] | jr3us: | so are all the functions in mythweb be in the embedded version? |
| [23:14:30] | skd5aner: | jr3us: yes, that would be the objective |
| [23:14:34] | stuartm: | it's impossible to enforce roadmaps when no-one can know whether they are going to have the time to work on something – that's just a fact of volunteer run projects |
| [23:14:52] | skd5aner: | stuartm: agreed... it's the nature of the beast |
| [23:15:06] | jr3us: | agreed stuartm |
| [23:16:11] | jr3us: | what port is embedded webserver on? |
| [23:16:50] | DrFoo: | What happens when you have lots of videos not in tmdb? Does 25 provide a way (auto or manual) to extract a preview? I see some scripts, but they seem a bit dated and am not sure about the functionality of the more current versions |
| [23:17:27] | jr3us: | me remind. found it on 6544 |
| [23:17:44] | jr3us: | never mind even |
| [23:17:51] | stuartm: | I would gladly have worked on the embedded webserver (along with a dozen other projects) if I had more time, it's one of the proposed features I strongly believe in because it simplifies setup and code |
| [23:18:23] | stuartm: | DrFoo: 25? |
| [23:18:34] | DrFoo: | 0.25 |
| [23:18:35] | skd5aner: | stuartm: yea, but people probably shouldn't stop working on existing features on the chance that it makes sense to eventually go in a different direction until it's certain that work is starting in that other direction and that that work will actually pan out |
| [23:20:21] | skd5aner: | No one wants to work on a dead end, but it sucks when someone doesn't work on something they might otherwise work on because they think it'll be a dead end and it really isn;t (or at least not for several releases) |
| [23:20:56] | stuartm: | yeah, agreed |
| [23:21:32] | jr3us: | mythweb is mostly pHp right? |
| [23:23:26] | skd5aner: | yes |
| [23:23:54] | stuartm: | yes, which counts against it because most devs aren't familiar enough with php to duplicate the features they've added in to the backend in PHP |
| [23:25:32] | jr3us: | what is the embedded webservice written in? c++? |
| [23:26:02] | stuartm: | in theory once the backend is serving the pages, you can re-use the code you've already written, saving effort, time and avoiding inconsistencies in behaviour – you also get lots of developers able to maintain it instead of the one or two we've had for the last few years |
| [23:26:07] | stuartm: | jr3us: yes |
| [23:27:26] | papertigers (papertigers!~papertige@pool-98-118-156-189.bflony.fios.verizon.net) has joined #mythtv | |
| [23:30:01] | jr3us: | is 6544 the same port that torc for ios uses to communicate with the backend? |
| [23:31:13] | DrFoo: | stuartm: sorry meant v0.25 not 25 |
| [23:31:40] | jr3us: | never mind .. it is |
| [23:35:34] | jr3us: | going back to monitor mode . I appreciate the information! |
| [23:35:49] | jr3us (jr3us!~jr3us2@cpe-098-026-209-039.triad.res.rr.com) has left #mythtv () | |
| [23:36:15] | skd5aner: | stuartm: monitoring mode? nah... the devs love it when you question their intents ;-) |
| [23:36:31] | skd5aner: | er, I mean jr3us, but he left anyway |
| [23:38:23] | jya: | peper03: do you know if there's a change in video resolution between the two streams your skipping ? |
| [23:38:40] | jya: | either resolution change, or bitrate change |
| [23:40:15] | jya: | peper03: sounds like a racing conditions… there are so many in mythtv code ..that it works so well is actually a surprised to me many times |
| [23:51:03] | stuartm: | DrFoo: mythpreviewgen, although I can't remember if it worked against videos in 0.25, that feature was definitely there in 0.26 though – still not what you'd call slick though, it can create the preview for a video but won't automatically write it into the screenshots storage group or update the database to display it for the video, so you need to go into the metadata editor and associate it there |
| [23:52:05] | stuartm: | could be scripted to do all that 'automatically', but I'm not aware that anyone has done that (yet) |
| [23:56:04] | papertigers (papertigers!~papertige@pool-98-118-156-189.bflony.fios.verizon.net) has quit (Ping timeout: 240 seconds) | |
| [23:56:44] | papertigers (papertigers!~papertige@pool-98-118-156-189.bflony.fios.verizon.net) has joined #mythtv | |
| Thursday, July 25th, 2013 | ||
| [00:00:01] | _nyloc_ (_nyloc_!~quassel@p4FE4D0E5.dip0.t-ipconnect.de) has quit (Ping timeout: 276 seconds) | |
| [00:04:12] | papertigers (papertigers!~papertige@pool-98-118-156-189.bflony.fios.verizon.net) has quit (Quit: papertigers) | |
| [00:15:36] | dmfrey (dmfrey!~dmfrey@65-78-98-83.c3-0.smt-ubr1.atw-smt.pa.cable.rcn.com) has joined #mythtv | |
| [00:22:52] | nyloc (nyloc!~quassel@pC19F51CD.dip0.t-ipconnect.de) has joined #mythtv | |
| [00:28:40] | jya: | stuartm: oh well, I've renamed mythuinotificationcenter into mythnotificationcenter |
| [00:32:28] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!) | |
| [00:40:13] | robink (robink!~quassel@unaffilated/robink) has joined #mythtv | |
| [01:14:51] | Chutt (Chutt!~ijr@cpe-76-190-199-73.neo.res.rr.com) has joined #mythtv | |
| [01:19:59] | magoogle (magoogle!47a39921@gateway/web/freenode/ip.71.163.153.33) has joined #mythtv | |
| [01:20:34] | magoogle: | when i try and manuallly assign an address to my ceton card it does not allow my primary network interface to keep an IP even if I also set that one manually? |
| [01:20:57] | magoogle: | oops just read the opening line lol ill try the other channel |
| [01:44:04] | danielk22: | stitchnot: IIRC FindAudioKeyframes() was a flagrant hack to prevent MythTV from freezing up the moment somebody tried to skip through an audio recording. No attempt was made to synchronize this with AC3 other other framed audio or to even use pts/dts for PCM audio. |
| [02:13:43] | xris: | Captain_Murdoch: seattle (gnu) linux conference is back on. want to give a talk about mythtv? :) |
| [02:24:38] | dmfrey (dmfrey!~dmfrey@65-78-98-83.c3-0.smt-ubr1.atw-smt.pa.cable.rcn.com) has quit (Quit: Ex-Chat) | |
| [02:26:48] | peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Ping timeout: 246 seconds) | |
| [02:27:50] | peper03 (peper03!~peper03@mythtv/developer/peper03) has joined #mythtv | |
| [02:31:53] | _nyloc_ (_nyloc_!~quassel@pC19F5D21.dip0.t-ipconnect.de) has joined #mythtv | |
| [02:35:33] | nyloc (nyloc!~quassel@pC19F51CD.dip0.t-ipconnect.de) has quit (Ping timeout: 246 seconds) | |
| [03:57:41] | DrFoo: | It seems that all my odd problems are due to the fact that Myth doesn't "see" videos in my videos directory. I have a mounted cifs share (/mnt/Tesla/media/videos) listed in the video directory field. |
| [03:58:14] | DrFoo: | When I select Watch Videos it tells me it can't find any or that there are none there and sends me to / |
| [03:59:30] | DrFoo: | If I navigate manually to /mnt/Tesla/media/videos/ they are there and readable. I don't see why myth doesn't recognize it automatically. |
| [04:02:09] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 248 seconds) | |
| [04:03:59] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [04:19:17] | pkendall (pkendall!~kvirc@219-89-45-241.dialup.xtra.co.nz) has quit (Ping timeout: 248 seconds) | |
| [04:29:23] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [04:30:05] | stichnot: | danielk22: that makes sense. |
| [04:32:46] | pkendall (pkendall!~kvirc@219-89-45-121.dialup.xtra.co.nz) has joined #mythtv | |
| [04:46:04] | pkendall (pkendall!~kvirc@219-89-45-121.dialup.xtra.co.nz) has quit (Ping timeout: 256 seconds) | |
| [04:55:14] | Casper0082 (Casper0082!~Casper@pool-108-36-208-246.phlapa.fios.verizon.net) has joined #mythtv | |
| [04:57:33] | Guest21029 (Guest21029!~Casper@unaffiliated/kc) has quit (Ping timeout: 240 seconds) | |
| [04:59:16] | pkendall (pkendall!~kvirc@219-89-46-191.dialup.xtra.co.nz) has joined #mythtv | |
| [05:12:09] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 264 seconds) | |
| [05:15:40] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [05:23:36] | Casper0082 is now known as kc | |
| [05:23:51] | kc (kc!~Casper@pool-108-36-208-246.phlapa.fios.verizon.net) has quit (Changing host) | |
| [05:23:52] | kc (kc!~Casper@unaffiliated/kc) has joined #mythtv | |
| [05:44:30] | peper03: | jya: There's no resolution change as I'm just jumping between chapters on a DVD. Bitrate probably is changing just because I would expect it to have been encoded with a variable bitrate. |
| [05:49:21] | peper03: | It certainly seems to be basically caused by the player thread flushing/freeing resources used by the decoder thread with no synchronization. I get a crash in the decoder thread, look at the player thread and it's suspiciously working through AvFormatDecoder::SeekReset flushing, freeing and discarding with not a semaphore in sight :( |
| [05:53:02] | fetzerch_ (fetzerch_!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [05:53:37] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 248 seconds) | |
| [05:55:20] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 261 seconds) | |
| [05:58:46] | joki (joki!~joki@p548628EC.dip0.t-ipconnect.de) has quit (Ping timeout: 246 seconds) | |
| [06:01:47] | SteveGoodey (SteveGoodey!~steve@host86-160-206-25.range86-160.btcentralplus.com) has joined #mythtv | |
| [06:03:49] | joki (joki!~joki@p54862AFC.dip0.t-ipconnect.de) has joined #mythtv | |
| [06:07:09] | pkendall (pkendall!~kvirc@219-89-46-191.dialup.xtra.co.nz) has quit (Quit: KVIrc 4.1.3 Equilibrium http://www.kvirc.net/) | |
| [06:11:42] | SteveGoodey (SteveGoodey!~steve@host86-160-206-25.range86-160.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [06:35:31] | tris (tris!tristan@2001:1868:a00a::4) has quit (Ping timeout: 266 seconds) | |
| [07:14:08] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [07:30:42] | skd5aner (skd5aner!~skd5aner@50-90-5-146.res.bhn.net) has quit (Ping timeout: 264 seconds) | |
| [07:31:58] | skd5aner (skd5aner!~skd5aner@50-90-5-146.res.bhn.net) has joined #mythtv | |
| [07:35:21] | Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:14ab:e6f3:8fe6:ddcd) has joined #mythtv | |
| [08:13:24] | jya: | peper03: yes.. sounds typically like a racing conditions… |
| [08:14:33] | jya: | maybe we could change the logic of the player never flushing anything, just asking for flushing to be done which is to be handled by the decoder thread |
| [08:53:26] | len (len!~quassel@75-168-36-94.mpls.qwest.net) has quit (Remote host closed the connection) | |
| [08:55:50] | peper03: | jya: That's possibly the only way to do it safely. If the playback profile is set to use more than one decoder thread, I don't know whether it's possible to synchronize them all as they're created by ffmpeg (unless I'm mistaken). The player might need to wait for the main decoder thread to signal 'ok', though. Don't know whether that's necessary or not. |
| [08:56:29] | jya: | the other possibility is simply add a lock, and wait until the decoder is finished processing the current frame |
| [08:57:10] | jya: | do you have a backtrace of a crash? |
| [09:05:25] | peper03: | jya: http://pastebin.com/AVFGpXJK – That's with a single decoding thread. |
| [09:06:13] | jya: | to reproduce it, all you do is skip forward / backwward a few times |
| [09:06:24] | jya: | how do you skip one chapter forward and one chapter backward? |
| [09:06:44] | peper03: | jya: Yes. I just hit page up/down. |
| [09:06:57] | jya: | ok…. need to find a DVD and try. |
| [09:07:03] | jya: | did you open a ticket? |
| [09:07:18] | peper03: | It seems to be a bit harder to do with one decoding thread (which makes sense). |
| [09:07:34] | peper03: | No, not yet. Wanted to make sure I wasn't missing something obvious. |
| [09:07:36] | jya: | you have h264 DVD ? |
| [09:07:53] | peper03: | Is there such a thing? |
| [09:07:56] | jya: | can't think of another codec type that would use multiple decoder thread |
| [09:08:04] | jya: | I mean, DVD being mpeg2 |
| [09:08:17] | jya: | AFAIK, it's always a single decoding thread |
| [09:08:40] | aca20031 (aca20031!~aca@2607:5300:60:2c95::1) has joined #mythtv | |
| [09:09:02] | peper03: | Don't know about the details. Just see it often segfaulting in a worker thread. Think it's mainly trying to report progress. |
| [09:09:28] | jya: | ok… I see if I can reproduce it first… then will go from there |
| [09:20:41] | peper03: | jya: Here's another trace using 2 threads: http://pastebin.com/gJ71uBYS |
| [09:53:40] | jya: | peper03: The first DVD I found was a barbie DVD… I see the first Universal jingle… Then I get to the menu to choose the language to choose. I press Enter. I see one error about decoding error. |
| [09:53:48] | jya: | from that point on, I can do nothing. |
| [09:54:04] | jya: | there's nothing showing on the log |
| [09:54:20] | jya: | It's not hanged, I can press ESC to return to the main menu |
| [09:54:39] | jya: | the last time I played that DVD with with 0.26, and it certainly played well. My daughter watches it often |
| [09:58:48] | jya: | it seems to be stuck on the decoder thread IsErrored() |
| [10:00:07] | peper03: | jya: *sigh* What video decoder are you using? Is the 'Extra audio buffering' option enabled? |
| [10:00:34] | jya: | I'm on a mac, I use the default OpenGL video profile |
| [10:00:37] | jya: | OpenGL High Quality |
| [10:00:52] | peper03: | Do you have the changes I pushed on Tuesday? |
| [10:01:11] | jya: | I did a git pull this afternoon |
| [10:01:31] | jya: | When I do a gdb pause |
| [10:01:41] | jya: | I'm always in the MythPlayer::DecoderLoop |
| [10:01:55] | jya: | on the while (!killdecoder && !IsErrored()) line |
| [10:02:19] | jya: | called from DDLoader destructor |
| [10:03:07] | jya: | to be honnest, where it is doesn't make much sense to me... |
| [10:03:18] | jya: | I'm going to recompile and restart |
| [10:04:20] | peper03: | Ok. Do you have the 'Extra audio buffering' option enabled? That was causing problems because the frames buffered by the decoder were not getting through to the player. |
| [10:05:15] | jya: | I don't believe so but let me check |
| [10:05:25] | jya: | it's really the default config on mac |
| [10:05:43] | jya: | ah yes, it's checked |
| [10:05:46] | jya: | is that the default? |
| [10:06:04] | peper03: | Can't remember. Try turning it off and then try again. |
| [10:06:53] | jya: | ah it plays now ! just recompiling and restarting fixed it.. |
| [10:07:00] | jya: | maybe it's a false alarm… sorry for that |
| [10:07:07] | jya: | that's with extra audio checked |
| [10:07:58] | peper03: | np. Good, then my fixes have hopefully worked and there isn't another corner case hiding and lurking somewhere :) |
| [10:08:11] | jya: | jeez, how much ads can this DVD have !! |
| [10:08:20] | jya: | I don't even know how to start playback yet. |
| [10:08:53] | peper03: | As it's a kids' DVD, more ads than you can shake a stick at :) |
| [10:09:08] | jya: | I'm on the main menu finally. It's impossible to tell which option is currently selected :( |
| [10:09:29] | peper03: | *sigh* |
| [10:09:40] | jya: | ah… it finally appeared the highlight |
| [10:09:44] | jya: | took a good minute :( |
| [10:10:16] | jya: | oh, I got a crash after my first page down :) |
| [10:10:23] | jya: | now that's good news (somewhat) |
| [10:10:46] | peper03: | Where did you land? |
| [10:10:55] | jya: | in av_parser_parse2 -> ff_aac_ac3_parse -> ff_combine_frame |
| [10:11:07] | jya: | /* Copy overread bytes from last frame into buffer. */ |
| [10:11:18] | peper03: | Sounds plausible. |
| [10:11:25] | jya: | in the decoder thread |
| [10:11:29] | peper03: | Where is the player thread? |
| [10:11:44] | jya: | where you seed. in SeekReset |
| [10:11:47] | jya: | you said |
| [10:11:54] | jya: | (damn autocorrection) |
| [10:12:18] | jya: | in DiscardVideFrames |
| [10:12:41] | peper03: | Ok, good (or not). At least it's not only me :) |
| [10:13:15] | jya: | it's actually AvFormatDecoderDVD::Read in the decoder thread |
| [10:13:55] | jya: | so probably would have to put some locking mechanism around the av_read_frame and the flushing in the player thread. |
| [10:14:09] | jya: | need to think about a way to do so, that will work under all circumstances |
| [10:15:15] | jya: | but if I have to suffer 4 minutes of barbie ads whenever I want to reproduce the issue, I'm going to get insane |
| [10:15:31] | peper03: | ReadPacket is called from AvFormatDecoder::GetFrame, so probably better to put it in there. |
| [10:15:38] | peper03: | Set a bookmark |
| [10:15:54] | peper03: | Or navigate directly to the menu (if it allows it). |
| [10:16:10] | jya: | when I selected root menu in the playback menu |
| [10:16:16] | jya: | that's where it got me to the ads |
| [10:16:22] | jya: | may have to try with another dvd |
| [10:16:45] | peper03: | Yeah, that happens sometimes. Bookmark is probably quickest. |
| [10:17:40] | jya: | problem is that if I can't get to it tomorrow, it will have to wait 2 weeks, as I'm going away on sunday |
| [10:18:03] | peper03: | I have a similar problem. |
| [10:18:25] | jya: | I think this just expose one of the core issue mythtv have |
| [10:18:37] | jya: | ffmpeg is fundamentally, not a thread-safe library |
| [10:18:45] | jya: | and we're doing it all over the place |
| [10:20:17] | jya: | I'm starting to think that the easiest would be to create a utility routine around av_read_frame... |
| [10:20:22] | jya: | protected by a lock |
| [10:20:39] | peper03: | And it's tricky to see just looking at the code which thread any given method is going to be running in. |
| [10:21:21] | jya: | the " Copy overread bytes from last frame into buffer. *" comment is a dead giveaway, that ffmpeg is expecting some data to be there, when we've just flushed it |
| [10:24:01] | peper03: | A lock around av_read_frame sounds reasonable. How do the ffmpeg worker threads work? |
| [10:25:48] | jya: | you mean our worker thread |
| [10:26:00] | jya: | FFmpeg doesn't have any separate thread |
| [10:26:07] | jya: | except if you do h264 decoding |
| [10:26:32] | jya: | took me 10 goes to make it crash this time |
| [10:28:04] | peper03: | Well, when I change the profile to use two decoder threads, I sometimes get a segfault in a worker thread (see the second link I sent before). |
| [10:28:22] | peper03: | Yeah, sometimes it's takes a few goes. |
| [10:28:37] | jya: | this isn't used… it's purely a coincidence |
| [10:29:00] | jya: | it's only relevant for h264 decoding following the merge of the h264 multi-threaded decoder |
| [10:29:09] | peper03: | So why is it segfaulting in it? |
| [10:29:29] | jya: | you always have two threads going |
| [10:29:40] | jya: | the GUI thread, which happens to now be the video player thread |
| [10:29:45] | jya: | and you have the decoder thread |
| [10:30:07] | jya: | in the decoder thread, FFmpeg itself can be configured to use more than the thread it's called from |
| [10:30:13] | jya: | that's for the h264 decoder |
| [10:31:16] | jya: | there used to be another thread, the videoplayer itself was running in another thread, but that all got removed following markk work a few years back |
| [10:31:34] | peper03: | That's what I meant. Sometimes I get a segfault in our decoder thread, sometimes in the ffmpeg worker thread. |
| [10:32:21] | jya: | well, this may have changed recently,… but AFAIK, ffmpeg only ever use more than one thread for h264 |
| [10:32:37] | jya: | so for DVD, the ffmpeg thread == Myth Decoder thread |
| [10:33:20] | jya: | the ffmpeg worker thread should do pretty much nothing but wait |
| [10:34:02] | jya: | I think the ffmpeg threads are just started because we told him to, but it's not actually used |
| [10:34:14] | peper03: | I think it may have changed, then. Call stack is worker->slice_decode_thread->mpeg_decode_slice->ff_MPV_report_decode_pr ogress->ff_thread_report_progress |
| [10:34:16] | jya: | now , I could be wrong |
| [10:34:31] | peper03: | -> Segfault |
| [10:35:40] | jya: | well, going page up when the dvd just start playback, it's almost guarantee to crash.. to press at the most |
| [10:35:54] | jya: | always in the same spot |
| [10:36:27] | peper03: | At least it's reproducible :) |
| [10:38:20] | peper03: | It probably doesn't really matter whether the extra thread is used or not. Although it's probably easiest to reproduce it with a DVD, it could occur with non-DVD sources, so also with h.264 sources, which means the extra thread(s) need to be considered. |
| [10:38:41] | jya: | I don;t think the DVD stuff has received much love before |
| [10:38:53] | jya: | i certainly don't use dvd playback much. |
| [10:39:00] | peper03: | I'm doing my best to rectify that :) |
| [10:39:14] | jya: | it could well be that in the standard avfd this doesn't occur |
| [10:39:34] | jya: | because they have the right locking in place |
| [10:40:03] | jya: | bluray playback will get just as much love hopefully.. |
| [10:40:08] | jya: | DVD are on their way out. |
| [10:40:38] | jya: | soon, even finding a computer with a DVD player is going to be a probleme. I see apple already has ditched it from all their new model |
| [10:41:53] | peper03: | I'm not sure. SeekReset isn't called directly but it is called indirectly from Reset, which is called from MythPlayer::ResetPlaying, which is turn is called from SwitchToProgram and JumpToProgram. I don't see any locking there (but maybe I haven't looked hard enough). |
| [10:42:19] | jya: | simple uh? |
| [10:42:45] | peper03: | If the locking is that high up (or higher), it shouldn't be. |
| [10:43:22] | peper03: | And I don't see any locking in AFD. No point only locking it on one side. |
| [10:45:10] | peper03: | I have a feeling that by the time the keys issue becomes a non-issue and all/most of the bugs have been found in the libraries, blu-ray will be on its way out too in favour of the next great thing. |
| [10:46:13] | jya: | actually, for 0.28, I want to start working on 3D playback |
| [10:46:25] | jya: | always be interested to see how that works. And I know nothing about it |
| [10:46:57] | jya: | just like myth was the first open player to support HD audio playback (with DTS-HD and TrueHD passthrough) |
| [10:47:04] | jya: | could be the first to support 3D |
| [10:47:26] | jya: | just playing bluray 3D |
| [10:47:46] | jya: | will let the job of the actual 3D bit to the TV and its glasses |
| [10:50:26] | peper03: | Would be nice to get native 3D support using VDPAU too (for the UI, I mean). It works already for OpenGL. Don't know if there's a technical reason why it can't be added to the VDPAU code. |
| [10:52:22] | jya: | I'm not sure most VDPAU core supports it. |
| [10:52:36] | jya: | it's a pretty addition |
| [10:52:55] | jya: | and I've seen no documentation about how to do it last I checked (about 3 months ago.. I got a 3D TV |
| [11:08:54] | jya: | peper03: actually, I strongly thing that the issue is local to the AVFDDVD |
| [11:09:14] | jya: | in all other decoder, the SeekReset is always called after getting the avcodeclock |
| [11:09:28] | jya: | but not for the DVD player |
| [11:10:09] | jya: | thinking of just moving the locking in seekreset itself, rather than the caller |
| [11:15:41] | peper03: | But shouldn't there be a lock in GetFrame, then? |
| [11:17:45] | dekarl1 (dekarl1!~dekarl@p4FE85F44.dip0.t-ipconnect.de) has joined #mythtv | |
| [11:17:50] | peper03: | Ideally, the lock should be in seekreset anyway. Get the lock as close to the critical part as possible to reduce the time spent in the lock and necessity to know that you need to get this lock before you call that method. |
| [11:18:03] | jya: | GetFrame itself doesn't need to be protected, it doesn't access ffmpeg stuff… Just that if you look in avformatdecoder.cpp; you see that in the change of frame format, it holds the lock, do the reset and continue |
| [11:18:21] | jya: | avcodeclock is a recursive mutex, so you can lock it multiple times |
| [11:18:50] | jya: | peper03: the problem with putting the lock in seekreset, is that it needs to be done in all the seekreset implementation |
| [11:19:07] | jya: | and as it's currently partially locked differently. I prefer to continue the way it was done. |
| [11:19:09] | dekarl (dekarl!~dekarl@p4FE85D9F.dip0.t-ipconnect.de) has quit (Ping timeout: 246 seconds) | |
| [11:19:11] | jya: | the change is less extensive that way |
| [11:20:01] | jya: | anyhow, I'm almost done.. going to do a quick test.. and then pass it on to you to test |
| [11:20:15] | jya: | could very well crash differently still |
| [11:20:19] | peper03: | GetFrame calls ReadPacket, which calls av_read_frame. |
| [11:20:35] | jya: | yes… the lock I put is just around readpacket |
| [11:20:41] | jya: | not the whole getframe |
| [11:21:24] | jya: | well, I think that did it ! |
| [11:22:56] | jya: | having the lock in SeekReset itself would certainly be simpler. |
| [11:23:27] | peper03: | Yes, I meant around the call to ReadPacket. GetFrame can sit in a loop for some time, I think before returning so not good to have it around the whole of that. |
| [11:24:10] | jya: | have a go with this: http://pastebin.com/9FdfSUny |
| [11:24:30] | jya: | I'm going to check if it's any simpler with the lock directly in seekreset instead |
| [11:24:39] | peper03: | I think we need a lock around the storedpackets stuff, too. I don't think I've seen a crash yet because of it, but the player sometimes empties it while the decoder (presumably) could be working on it. |
| [11:25:12] | jya: | we only need to lock the things accessing libav … |
| [11:25:15] | jya: | nothing else |
| [11:25:22] | jya: | not in this case |
| [11:25:41] | jya: | because the data in storedpacket, isn't used by libav |
| [11:25:51] | jya: | libav only use its own internal buffers |
| [11:26:06] | jya: | here it crashed because we flushed them half-way |
| [11:26:12] | jya: | in a different thread |
| [11:26:30] | peper03: | No, not in this case. That was what I was looking at originally and then found this problem in (more or less) the same place. |
| [11:26:56] | jya: | which functions are you referring to? |
| [11:29:56] | peper03: | http://irc.mythtv.org/ircLog/channel/4/2013-07-24:16:55:52 |
| [11:32:41] | jya: | ok.. I looked at that one. |
| [11:33:03] | jya: | and if you check the patch I've sent you, i've put a lock there too |
| [11:33:18] | jya: | though, I believe the one I have now, has less changes and work just as well. |
| [11:33:21] | jya: | going to test now |
| [11:33:51] | jya: | Im fairly certain of the outcome though |
| [11:37:22] | jya: | anyhow… it was a good find… I've seen crashes occurring during DVD playback before, and I wouldn't be surprised if that was the one |
| [11:38:14] | jya: | aren't the beginning of chapters starting with a reference frame? |
| [11:38:40] | jya: | every time I skip, the first few video frames one the skip occurred are blocks |
| [11:40:56] | jya: | I just realised.. MythTV was made over 33508 commits |
| [11:41:07] | jya: | we have 11705 bug reported |
| [11:41:29] | jya: | that's one bug for every 2.86 commits :) |
| [11:41:38] | jya: | got to be a record :D |
| [11:41:49] | peper03: | Although that includes all the invalid bug reports :) |
| [11:42:16] | jya: | peper03: want to test with this one? |
| [11:42:17] | jya: | http://pastebin.com/VUJSFhKJ |
| [11:42:36] | jya: | it's more elegant, and I believe fixes all issues… certainly can;t make it crash any longer |
| [11:43:18] | jya: | give me a yell when you did |
| [11:44:33] | jya: | could probably backport that one to 0.26 |
| [11:44:53] | peper03: | Ok, I have to go for a few hours. I can give it a quick test before I go, though. |
| [11:45:24] | jya: | thanks, that'll be appreciated.. then I can go and start watching my own movie.. lots of movies to catch up on… been doing too much myth lately |
| [11:48:14] | peper03: | Hmm. Doesn't want to apply. What's going on there? |
| [11:50:27] | peper03: | fatal: corrupt patch at line 65 |
| [11:53:18] | jya: | you applied the two patches after another ? |
| [11:53:22] | jya: | can't do that. |
| [11:53:35] | jya: | I think you're right in regards to StoredPackets |
| [11:53:36] | peper03: | No, only the second one. Or at least, that's one I'm trying to do. |
| [11:53:46] | peper03: | s/one/what/ |
| [11:53:55] | jya: | go into the git/mythtv, patch -p2 < patch.diff |
| [11:54:19] | peper03: | Line 65 is the last line. If I add a new line, it complains about line 6... |
| [11:54:41] | jya: | let me repost the patch.. maybe i made a mistake |
| [11:55:13] | jya: | http://pastebin.com/6MpU2Csw |
| [11:56:54] | jya: | so I think there could be a racing conditions in the handling of StoredPacket. Reset can modify it while it's being checked elsewhere. |
| [11:58:21] | jya: | however, it shouldn't be too much of an issue, at worse it will cause a leak in that a packet could be missed and only freed the next time reset is called. could also mean you have a reset, and right at the same time you have a new packet added, then the skip occured |
| [11:58:58] | jya: | that could cause some video corruption, but that will be recovered the next packet |
| [11:59:14] | peper03: | I'm not sure that isn't the cause of the blocks you mentioned before. |
| [11:59:17] | jya: | so not sure it's worth bothering about it… properly locking it is a bit invasive change |
| [11:59:33] | jya: | was thinking the same thing |
| [12:00:41] | peper03: | Ok, patch applied (duh, was in the wrong directory!). Give me a sec to try to make it crash :) |
| [12:03:43] | peper03: | Looks good. Doesn't usually take long to make it crash, so I think that's probably done it. |
| [12:05:11] | jya: | there's over 11 access to storedPackets in AVFD, and two in AVFDDVD… locking it isn't going to be that simple… unless I simply move the locking right at the beginning of getframe |
| [12:11:39] | peper03: | The first four occurences are loops in the destructor and SeekReset, so should be fairly straightforward to lock. The ones inside GetFrame need a bit more consideration. I'd be wary of locking the whole of GetFrame, personally, as it can loop for a while. Actually, it can stay in there indefinitely if you have a still frame with no timeout on a DVD. |
| [12:13:26] | peper03: | I can have a look at that later, if you like. I think storedpackets should be flushed in Reset too when reset_video_data is true. |
| [12:14:31] | jya: | peper03: well, there should be a lock in use whenever storedpacket is being accessed. |
| [12:14:53] | peper03: | Jumping usually causes a 'DVDNAV_HOP_CHANNEL' event, which should dump any buffers. At the moment, storedpackets aren't being dumped, which might be the cause of the blockiness. |
| [12:15:02] | jya: | in GetFrame I would put the lock inside the loop |
| [12:15:57] | peper03: | If you have a still frame, you won't come out of GetPacket until it's dismissed. |
| [12:16:29] | jya: | you mean readpacket? |
| [12:16:45] | peper03: | Sorry, yes. |
| [12:17:01] | jya: | but then you wouldn't do skip or seekreset in there no? |
| [12:17:54] | peper03: | Well, there shouldn't be. I haven't thought all the scenarios through. It's just that if the lock were taken and the player *did* try to do something, you'd have a deadlock. |
| [12:19:31] | dblain (dblain!~dblain@mythtv/developer/dblain) has quit (Ping timeout: 268 seconds) | |
| [12:20:12] | jya: | having said that, if the ReadPacket may not return quickly, we already have an issue now regardless |
| [12:20:32] | jya: | as we lock it now |
| [12:20:48] | peper03: | That's true. |
| [12:22:22] | jya: | do you have some samples with still frame where you could try to seek or skip ? |
| [12:23:50] | peper03: | Seek isn't supported in a still frame (at the moment). I think skip causes the still frame to be dismissed, so it may not be an issue. |
| [12:24:26] | peper03: | Once the still frame is dismissed, av_read_frame should return. |
| [12:24:41] | jya: | but will ReadPacket exit? |
| [12:26:26] | jya: | hum… maybe the locking shouldn't be done that way then… instead be placed around av_read_frame. |
| [12:27:03] | jya: | hum… no that won't do… anything touch ic needs to be locked |
| [12:30:11] | jya: | anyway, this needs further testing, and you're probably the only one with access to such test material |
| [12:31:29] | peper03: | Yes, ReadPacket should exit with the next video/data/audio/whatever packet. I'll do some testing later. Have to go. |
| [12:31:48] | peper03: | Thanks for the help! |
| [12:31:55] | stuartm: | note, I'm working on the news post, but first I've having to figure out and fix some issues with the system – notably that the last news post (0.26 release) wasn't actually committed and will be wiped if I push a new one |
| [12:41:38] | dblain (dblain!~dblain@mythtv/developer/dblain) has joined #mythtv | |
| [13:00:11] | jya: | peper03: is there any other method in avfd called by a different thread than the decoder one ? |
| [13:06:06] | purserj (purserj!~purserj@hosting.collaborynth.com.au) has quit (Ping timeout: 264 seconds) | |
| [13:07:02] | purserj (purserj!~purserj@113.212.99.150) has joined #mythtv | |
| [13:10:00] | stuartm: | news posted, need to fiddle with the formatting though |
| [13:10:30] | ** jya dear god… I watched the entire barbie movie ! ** | |
| [13:16:41] | stuartm: | there goes your cred |
| [13:25:26] | jya: | peper03: I think the issue with the locking is really only for DVD playback… The only place calling SeekReset outside the decoder thread is in MythDVDPlayer |
| [13:29:16] | peper03: | jya: MythPlayer::SwitchToProgram/JumpToProgram->ResetPlaying->AvFormatDecoder:: Reset->SeekReset |
| [13:30:15] | peper03: | stuartm: July 21th? th? |
| [13:30:32] | jya: | peper03: how do you jump program within an existing one so I can try ? |
| [13:31:00] | peper03: | jya: No idea. Just following the code. |
| [13:31:10] | jya: | just want to see in which thread it's running |
| [13:33:55] | peper03: | Both SwitchToProgram and JumpToProgram are called from MythPlayer::EventLoop, so presumably from the player thread. |
| [13:34:13] | jya: | yes.. was looking at that.. occurs when you change program in live tv |
| [13:35:22] | peper03: | I'm not aware of any other methods in avfd that are called by a thread other than the decoder thread, but then I wasn't aware of SeekReset before yesterday :) |
| [13:35:42] | stuartm: | peper03: oops, edited the date from automatically added one (25th) |
| [13:35:57] | jya: | if the issue was just in mythdvdplayer, then I would have added a mechanism similar to just seeking |
| [13:36:22] | jya: | the player set a seek value (here could be seekchapter) |
| [13:36:36] | jya: | and in the decoder loop you check that value and process into doing the work. |
| [13:36:41] | jya: | so no more locking required |
| [13:37:01] | stuartm: | peper03: err, no that was the one in Nicolas' email |
| [13:37:42] | jya: | stuartm: no link to the release note ? |
| [13:38:08] | peper03: | stuartm: Probably happened the same way, though. Just makes me start thinking with a lisp :) |
| [13:38:33] | stuartm: | jya: I'll add one |
| [13:41:55] | tris (tris!tristan@2001:1868:a00a::4) has joined #mythtv | |
| [13:45:32] | dmfrey (dmfrey!~dmfrey@webdefence.cluster-h.websense.net) has joined #mythtv | |
| [13:54:07] | stichnot: | jya: maybe Source > Jump to Program in the playback OSD menu |
| [13:55:45] | jya: | stichnot: ah good find… regardless, i think the issue is more complex anyway… I've fixed one aspect of it, but it's just not safe the way it is… You have the player accessing the decoder->ic context, with no lock of any kind, and it's obviously not safe to do so while the decoder thread is doing its business |
| [14:18:11] | tgm4883 (tgm4883!~tgm4883@ubuntu/member/tgm4883) has quit (Ping timeout: 264 seconds) | |
| [14:22:49] | tgm4883 (tgm4883!~tgm4883@ubuntu/member/tgm4883) has joined #mythtv | |
| [14:45:23] | bobweaver (bobweaver!~bobweaver@ubuntu/member/bobweaver) has joined #mythtv | |
| [15:04:00] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 260 seconds) | |
| [15:09:01] | peper03: | jya: Does it always take so long before the menu highlight appears on your Barbie DVD? If so, I'd be interested in traces and possibly a small sample. |
| [15:09:45] | bobweaver: | Just a update on how the SDK kit is coming together. a good waste of 3 minutes and 33 seconds of your life :) http://www.youtube.com/watch?v=rsi8alOlQ00 |
| [15:30:00] | Merlin83b2 (Merlin83b2!~Daniel@office.34sp.com) has joined #mythtv | |
| [15:30:18] | IReboot (IReboot!~doug@cpe10bf48e67915-cm78cd8e7e342d.cpe.net.cable.rogers.com) has joined #mythtv | |
| [15:32:04] | Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:14ab:e6f3:8fe6:ddcd) has quit (Ping timeout: 245 seconds) | |
| [15:39:27] | Chutt (Chutt!~ijr@cpe-76-190-199-73.neo.res.rr.com) has quit (Ping timeout: 256 seconds) | |
| [15:41:37] | Chutt (Chutt!~ijr@cpe-76-190-199-73.neo.res.rr.com) has joined #mythtv | |
| [15:57:34] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [16:00:22] | Jim_Lahey (Jim_Lahey!~bobweaver@173-86-138-82.dsl1-field.roch.ny.frontiernet.net) has joined #mythtv | |
| [16:00:45] | Jim_Lahey is now known as Guest45753 | |
| [16:03:04] | bobweaver (bobweaver!~bobweaver@ubuntu/member/bobweaver) has quit (Ping timeout: 256 seconds) | |
| [16:03:30] | knightr: | stuartm, Thank you! |
| [16:06:06] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 261 seconds) | |
| [16:11:35] | Guest45753 (Guest45753!~bobweaver@173-86-138-82.dsl1-field.roch.ny.frontiernet.net) has quit (Read error: No route to host) | |
| [16:12:49] | stuartm: | knightr: no need to thank me, sorry I didn't get it done sooner :) |
| [16:27:34] | rsiebert_ (rsiebert_!~quassel@e179134098.adsl.alicedsl.de) has quit (Read error: Operation timed out) | |
| [16:28:23] | rsiebert (rsiebert!~quassel@92.224.248.156) has joined #mythtv | |
| [16:40:16] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [16:41:12] | Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv | |
| [16:46:14] | lomion0815 (lomion0815!~lomion081@93-82-143-238.adsl.highway.telekom.at) has joined #mythtv | |
| [16:53:49] | Merlin83b2 (Merlin83b2!~Daniel@office.34sp.com) has quit (Read error: Connection reset by peer) | |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.