MythLogBot@irc.freenode.net :: #mythtv

Daily chat history

Current users (81):

aloril, amessina, Anssi, Beirdo_, brfransen, Captain_Murdoch, Chutt, clever, coling, Cougar, danielk221, dblain, dekarl, Draiodoir, ElmerFudd, ephemer0l, fetzerch, foxbuntu`, ghoti, Gibby_, gigem, gregL, GreyFoxx, Guest21244, IReboot, J-e-f-f-A, jarle, jarryd, jheizer, joe______, joki, jpabq, jpabq_, jpharvey, jst, jwhite, kc, kenni, kormoc, kurre2, kwmonroe, laga, len, MaverickTech, Merlin83b, moparisthebest, Mousey, mrand1, MythBuild, MythLogBot, neufeld, NightMonkey, petefunk, poptix, purserj_, rhpot1991, rsiebert, Seeker`, seld, Sharky-Sleep, skd5aner, sl1ce, SmallR2002_, sphery, sraue, stuarta, stuartm, superm1, taylorr, tgm4883, Tobbe5178, toeb, tonsofpcs, tris, unforgiven512, wagnerrp, wilmoore-misc, wolfgang3, XDS2010, xris, _charly_
Monday, May 6th, 2013, 00:08 UTC
[00:08:02] stichnot (stichnot!~stichnot@adsl-69-110-157-91.dsl.pltn13.pacbell.net) has joined #mythtv
[00:08:03] stichnot (stichnot!~stichnot@adsl-69-110-157-91.dsl.pltn13.pacbell.net) has quit (Changing host)
[00:08:03] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[00:15:40] jya: danielk221: I made some changes to the ringbuffer class yesterday, allowing to change the size of the buffer used. At first I thought it was related to how ffmpeg was caching thing and using the buffer. Now however, I'm fairly convinced the issue is in our code only. When reading data , I don't always get the same content when the cache size is bigger (which causes playback to fail here)
[00:17:55] danielk221: jya: Can I see the changes you made?
[00:18:12] jya: https://github.com/MythTV/mythtv/commit/3345a . . . e6e7659bf323
[00:18:45] danielk221: looking
[00:19:34] jya: the other interesting thing is that the size of the buffer also has an impact elsewhere… If I was to use 2kB for everything: everything works fine. If I was to use 4kB I can read the moov table fine, but then it won't play due to "audio behind by xxxms"
[00:20:03] jya: 32kB allows to play well, but when reading the moov table, for some videos it will read a 0 and exit early
[00:25:30] danielk221: jya: The CHUNK size is hard coded in the ringbuffer as 32768. Try setting that to 2048 bytes @ ringbuffer.cpp@42 & in avformatdecoder.
[00:25:49] jya: oh, I have played with that ..
[00:25:54] jya: and setting it to 2048 will work
[00:26:07] jya: that's the whole point of my commit…
[00:26:17] jya: change the buffer size temporarily
[00:26:49] danielk221: jya: Is there any negative impact to just setting it to 2KB? It's not like these are real reads 99.9% of the time..
[00:27:17] jya: I don't know.. I tried no to stray from the original code or logic by too much...
[00:27:56] jya: so what's the difference between RingBuffer::BestBufferSize and CHUNK size?
[00:29:48] jya: BestBufferSize is the value we're providing to ffmpeg avio code
[00:30:10] jya: but let me try just changing CHUNK size then..
[00:30:15] jya: reverting my change
[00:30:18] danielk221: CHUNK is what is actually used in RingBuffer..
[00:33:05] danielk221: FYI I had done some experimenting with the read size 6 months ago. I had pretty much concluded that 2KB would be a much better buffer size to use in avformatdecoder & RingBuffer all the time. But I wanted to convince myself it wouldn't have a significant impact on lower spec systems, and then I changed jobs and didn't have any time for MythTV for a while..
[00:34:17] danielk221: The point of BestBufferSize() is that it is a virtual so say a DVDRingBuffer can always return 2KB and use 2KB reads because that makes sense with DVDs.
[00:34:19] jya: danielk221: I remember the issue with AVI interleaved file that didn't play with the current 32kB buffer
[00:34:34] jya: but would with 2kB
[00:35:55] jya: hum… nope… having chunk size at 2kB but BestBufferSize returns 32kB doesn't help for my .mov file
[00:36:07] danielk221: jya: Change both..
[00:36:28] jya: if I only change BestBufferSize to 2kB then it works fine
[00:36:48] jya: BestBufferSize=2kB and CHUNK size = 32kB : all good
[00:37:01] jya: but provided ffmpeg uses a 32kB default buffer.
[00:37:09] danielk221: jya: really? cool.
[00:37:36] jya: I didn't want to use a 2kB buffer only , I felt that it was changing to much compare to the existing code
[00:37:37] danielk221: I wouldn't expect things to work well with BestBufferSize() != CHUNK.
[00:38:12] jya: what tells me that the issue is in our code is this:
[00:38:53] jya: if I modify InitByteContext , and don't set the ic->pb member: ffmpeg will re-open the file automatically: and then it works
[00:39:04] jya: it's only when we use our own ringbuffer that it fails
[00:42:13] jya: changing chunk code to 2kB and for streamingringbuffer to change from 32kB to 2kB would be a less invaisve change, and it works well...
[00:42:19] danielk221: hmm
[00:42:46] jya: at least for the .mov I'm desperately trying to get around
[00:43:56] jya: very bizarre that with a buffer 2kB is works. With 4kB I can read the .moov but can't play the file (get audio behind video by xxms), with > 4kB I can't read the .moov (at some stages it reads some zeros, and ffmpeg exit with an error)
[00:43:57] memoryguy (memoryguy!~androirc@bas2-toronto42-2925485019.dsl.bell.ca) has joined #mythtv
[00:44:06] tonsofpcs: are you screwing with vbuffers?
[00:44:20] memoryguy (memoryguy!~androirc@bas2-toronto42-2925485019.dsl.bell.ca) has quit (Client Quit)
[00:44:46] memoryguy (memoryguy!~androirc@bas2-toronto42-2925485019.dsl.bell.ca) has joined #mythtv
[00:44:50] jya: no, only playing with the ringbuffer size (and ffmpeg avio buffer size)
[00:46:25] jya: the moov data is at the end of the mov file I'm trying to play… with an avio buffer size of 2 or 4kB, it seeks to the end of the file, and read the data fine. with an avio buffer size of 32kB , when it seeks to the end, it starts reading 0 for the size of the index
[00:46:33] danielk221: jya: Has URLProtocol changed in any recent ffmpeg? the code in avfringbuffer.cpp:86+ is designed to be resistant to changes breaking things, but if a new required method has been added we may not be initializing the pb correctly.
[00:47:12] jya: using the default ffmpeg ffurl_blah() ; removing our ringbuffer thing, it uses 32kB buffer, but everything works well
[00:47:29] danielk221: jya: wacky
[00:48:05] jya: danielk221: no there's no changes in ffmpeg at this level. Changes occurred in release 0.9 that we used in 0.26, and I had made changes at the time to be resilient to ffmpeg changes
[00:49:22] danielk221: jya: The seek to the end of the file may be key.
[00:49:51] jya: danielk221: yeah, I delved in there for a while… but couldn't fault anything...
[00:49:54] memoryguy (memoryguy!~androirc@bas2-toronto42-2925485019.dsl.bell.ca) has quit (Remote host closed the connection)
[00:50:09] memoryguy (memoryguy!~androirc@bas2-toronto42-2925485019.dsl.bell.ca) has joined #mythtv
[00:50:09] jya: it starting to become very hard to debug that code, it goes into deep TCP connectivity in ffmpeg
[00:50:28] danielk221: if you set the buffer size to 16KB does that work?
[00:50:33] jya: and when I add logs or breakpoint, it threw away the timing and it would error eleswhere
[00:50:37] jya: nope
[00:50:52] jya: I found that only 2kB or 4kB works when it comes to reading the .moov table
[00:52:06] jya: the difference between something that works and one that doesn't. Is in libavformat/mov.c , line 2798 : the a.size = avio_rb32(pb);
[00:52:06] danielk221: How far in bytes from the end is the seek before reading the moov table?
[00:52:13] jya: will give me a zero at some stage
[00:52:33] jya: it's right there… like 2kB ahead
[00:52:52] jya: tbh, I don't know
[00:53:16] jya: i spent a good 3 days on this … I found something that works. But I hate it because I don't know exactly why
[00:53:30] jya: just getting around a problem without fixing it ; and I hate those type of fixes
[00:53:53] danielk221: I'm there with you. If you fix something without knowing why you don't know if it is really fixed for good.
[00:54:42] jya: ok, If I set the aviobuffer to 4kB , reading the moov table works okay too
[00:55:09] danielk221: One thing that happens near the end of a file is if we return 0 bytes from a read enough times ffmpeg will set an internal is_eof flag and stop reading.
[00:55:18] jya: e.g. setting DiscoveryBufferSize to 4kB is okay
[00:57:00] jya: ok, in that particular file: avio_tell returns 29751229
[00:57:18] jya: the file size is 102320208
[00:57:20] jya: bytes
[00:57:54] danielk221: oh, so not really near the end of the file at all.
[00:58:18] jya: hum… nah… it was nealy the end of the file.. probably reading in the wrong place
[00:58:27] jya: let me plut a breakpoint in the seek routing
[00:59:30] jya: ohhh. my bad.. I'm not playing the file I tried with usually :)
[00:59:36] danielk221: heh
[01:00:22] jya: seek is to: 102296059
[01:00:49] jya: so 24kB before the end
[01:01:15] danielk221: ok, that is interesting. I bet a 24KB buffer would work then.
[01:01:21] jya: the start_pos in the moov code is at: 102296067
[01:01:34] jya: let me try
[01:03:14] jya: you're right...
[01:03:23] jya: I set the buffer at 24149 and it works
[01:04:17] danielk221: ok I'm looking at the man page for read and seeing how it differs from the safe_read in fileringbuffer.cpp:411
[01:04:32] jya: sounds like when we;re trying to read too much of it (as we're at the eof), the buffer isn't filled properly before
[01:04:43] jya: hence the 0
[01:06:16] jya: brb
[01:07:38] danielk221: jya: I think it may be some detail of C's read() not captured by the man page for read but relied on by ffmpeg. Such as the exact details of how EOF is handled on the second read after EOF.
[01:08:28] sabbath1 (sabbath1!~sabbath@125.sub-174-236-160.myvzw.com) has joined #mythtv
[01:08:45] danielk221: From this: http://unixhelp.ed.ac.uk/CGI/man-cgi?read+2 it would look like we do the right thing. Return the bytes read when a 32KB read is done 24KB from the end of the file and then return 0 on the next read.
[01:08:58] sabbath1 (sabbath1!~sabbath@125.sub-174-236-160.myvzw.com) has left #mythtv ()
[01:10:47] danielk221: http://pubs.opengroup.org/onlinepubs/9699919799/
[01:11:12] danielk221: "When attempting to read a file (other than a pipe or FIFO) that supports non-blocking reads and has no data currently available: If O_NONBLOCK is set, read() shall return -1 and set errno to [EAGAIN]."
[01:13:01] danielk221: Returning
[01:16:28] jya: but is the ffurl_read_complete used in streamingringbuffer does the right thing?
[01:16:28] jya: ffurl_read_complete
[01:17:10] jya: let me put a breakpoint in that function and see if ffmpeg using their default file access (removing our ringbuffer) calls it
[01:21:20] danielk221: I don't think we're event setting AVIO_FLAG_NONBLOCK so this POSIX quote is probably not pertinent.
[01:21:28] danielk221: s/event/even/
[01:25:18] jya: ffurl_read_complete is never called when using pure ffmpeg
[01:26:09] jya: it only uses ffurl_read
[01:28:57] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 252 seconds)
[01:31:19] danielk221: hmm is the difference that ffurl_read reads 1 byte at a time?
[01:32:03] danielk221: nope, ffurl_read will simply accept anything more than 1 byte.
[01:32:25] danielk221: Sound like what we should be using rather than ffurl_read_complete
[01:33:32] danielk221: The only reason we try to read the full buffer in filereadbuffer is because ffmpeg will set the internal eof flag if we reach the current end-of-file in a growing file.
[01:34:10] danielk221: I presume that isn't really a risk with the StreamingRingBuffer.
[01:46:27] jya: danielk221: I'm adding logs to safe_read in streamingringbuffer… it is called twice only before ffmpeg error. First time to read 2kB. Second time to read 32kB, and there it errors ffurl_read_complete returning -541478725
[01:47:03] jya: danielk221: I had tried earlier to replace read_complete with read, that fails miserably everywhere
[01:47:39] jya: danielk221: streamingringbuffer is used for streaming file, as well as fixed file (like mp3 youtube videos)
[01:49:03] danielk221: The API of RingBuffer::safe_read() is to return only positive numbers and return any error in errno. so if ffurl_read_complete() returns negative numbers it will need some wrapping.. but it is obviously not doing the right thing if it isn't returning the remaining bytes before then...
[01:49:44] danielk221: .. it's time for me to head to bed .. I'll catch up with chat in the morning.
[01:50:25] jya: hum… safe_read returns a negative number in almost all subclasses of ringbuffer
[01:52:39] jya: the dvdringbuffer for example, set errno but returns -1
[01:52:53] jya: and I see that the ringbuffer code test the returned value to check if it's positive or not
[01:57:51] jya: danielk221: retry_transfer_wrapper used by ffmpeg, when it reads less than the required number of bytes, return an error code rather than the number of bytes actually read
[01:58:31] jya: sounds like a bug in ffmpeg
[01:59:49] danielk221: jya: Yeah sounds like an upstream bug.
[02:00:15] jya: I can see that it read 24149 bytes so far (which is the end of the file)
[02:00:16] danielk221: yes, sorry we return -1; but we don't do what ffmpeg does and return -errno when there is an error.
[02:00:45] jya: and the next call it returns the error code, but the 24149 value is now lost...
[02:03:04] danielk221: jya: I'm pretty sure you found a genuine bug. File a bug report. This should be pretty easy for the ffmpeg devs to fix. Filing a patch might actually slow down the process of getting it fixed.
[02:04:02] jya: I can see what they are going to answer though...
[02:04:16] danielk221: of course they may say it is "as designed"..
[02:04:18] jya: because last I lodged a bug about avio that's what happend.
[02:04:47] jya: avio isn't a public API ; what we are doing with setting our own SEEK/READ/SIZE code is not supported
[02:05:25] jya: but can certainly try
[02:05:35] jya: it's a bit less grey area this time...
[02:05:52] memoryguy (memoryguy!~androirc@bas2-toronto42-2925485019.dsl.bell.ca) has quit (Remote host closed the connection)
[02:06:04] memoryguy (memoryguy!~androirc@bas2-toronto42-2925485019.dsl.bell.ca) has joined #mythtv
[02:06:10] memoryguy (memoryguy!~androirc@bas2-toronto42-2925485019.dsl.bell.ca) has quit (Read error: Connection reset by peer)
[02:07:43] danielk221: They may say anything less than a complete read is an error. But it is worth a try
[02:07:59] jya: yeah, the http_buf_read returns AVERROR_EOF ; and so safe_read returns EOF too
[02:07:59] danielk221: Anyway, really time for bed :)
[02:08:14] jya: good night
[02:08:20] jya: thanks for the set of eyes
[02:09:02] tonsofpcs: so I have a show that's showing as a rerun in listings but has new="true" set in the SchedulesDirect data.
[02:19:58] Oryx (Oryx!~Oryx@pool-71-179-90-4.bltmmd.fios.verizon.net) has joined #mythtv
[02:20:58] Oryx (Oryx!~Oryx@pool-71-179-90-4.bltmmd.fios.verizon.net) has left #mythtv ("PRIVMSG #mythtv-users :I'm at a loss trying to get mythtv to work with an HDHomeRun Prime, anyone have experience with either the prime or non-prime model?")
[02:24:48] sharky-wtf (sharky-wtf!~Sharky112@c-24-19-57-28.hsd1.wa.comcast.net) has joined #mythtv
[02:26:00] Sharky-Sleep (Sharky-Sleep!~Sharky112@c-24-19-57-28.hsd1.wa.comcast.net) has quit (Ping timeout: 264 seconds)
[02:31:43] sharky-wtf (sharky-wtf!~Sharky112@c-24-19-57-28.hsd1.wa.comcast.net) has quit (Ping timeout: 256 seconds)
[02:36:02] Sharky-Sleep (Sharky-Sleep!~Sharky112@c-24-19-57-28.hsd1.wa.comcast.net) has joined #mythtv
[03:41:21] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 248 seconds)
[03:42:37] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv
[04:32:30] aloril (aloril!~aloril@dsl-tkubrasgw3-54f97e-153.dhcp.inet.fi) has quit (Ping timeout: 256 seconds)
[04:38:44] stichnot (stichnot!~stichnot@adsl-69-110-157-184.dsl.pltn13.pacbell.net) has joined #mythtv
[04:38:44] stichnot (stichnot!~stichnot@adsl-69-110-157-184.dsl.pltn13.pacbell.net) has quit (Changing host)
[04:38:44] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[04:46:00] aloril (aloril!~aloril@dsl-tkubrasgw3-54f97e-153.dhcp.inet.fi) has joined #mythtv
[04:51:58] Sharky-Sleep (Sharky-Sleep!~Sharky112@c-24-19-57-28.hsd1.wa.comcast.net) has quit (Ping timeout: 256 seconds)
[04:54:27] Sharky-Sleep (Sharky-Sleep!~Sharky112@c-24-19-57-28.hsd1.wa.comcast.net) has joined #mythtv
[05:50:31] wilmoore-misc (wilmoore-misc!~wilmoore@c-67-190-17-108.hsd1.co.comcast.net) has joined #mythtv
[05:51:00] dekarl1 (dekarl1!~dekarl@p4FCEFF02.dip0.t-ipconnect.de) has joined #mythtv
[05:51:16] dekarl (dekarl!~dekarl@p4FCEFBEB.dip0.t-ipconnect.de) has quit (Ping timeout: 256 seconds)
[06:11:51] FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has joined #mythtv
[06:53:01] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv
[07:05:40] stuartm: tonsofpcs: does it have an originalairdate?
[07:15:12] coling (coling!~colin@cpc7-sgyl36-2-0-cust267.18-2.cable.virginmedia.com) has quit (Quit: leaving)
[07:25:18] coling (coling!~colin@cpc7-sgyl36-2-0-cust267.18-2.cable.virginmedia.com) has joined #mythtv
[07:26:06] toeb (toeb!~tob@HSI-KBW-37-49-118-160.hsi14.kabel-badenwuerttemberg.de) has joined #mythtv
[07:35:22] SteveGoodey (SteveGoodey!~steve@host86-140-98-12.range86-140.btcentralplus.com) has joined #mythtv
[07:36:49] Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:2856:2c81:e5d7:1966) has joined #mythtv
[08:30:00] SteveGoodey (SteveGoodey!~steve@host86-140-98-12.range86-140.btcentralplus.com) has quit (Ping timeout: 272 seconds)
[08:49:52] knightr (knightr!~knightr@mythtv/developer/knightr) has quit (Read error: Connection reset by peer)
[08:50:18] knightr (knightr!~knightr@69-165-170-178.dsl.teksavvy.com) has joined #mythtv
[08:50:18] knightr (knightr!~knightr@mythtv/developer/knightr) has joined #mythtv
[08:50:18] knightr (knightr!~knightr@69-165-170-178.dsl.teksavvy.com) has quit (Changing host)
[08:53:21] len (len!~quassel@75-161-175-43.mpls.qwest.net) has quit (Remote host closed the connection)
[08:57:30] wilmoore-misc (wilmoore-misc!~wilmoore@c-67-190-17-108.hsd1.co.comcast.net) has quit (Remote host closed the connection)
[09:00:02] wilmoore-misc (wilmoore-misc!~wilmoore@c-67-190-17-108.hsd1.co.comcast.net) has joined #mythtv
[09:42:08] SteveGoodey (SteveGoodey!~steve@host86-140-98-12.range86-140.btcentralplus.com) has joined #mythtv
[09:44:19] GreyFoxx (GreyFoxx!~greg@out.of.phaze.org) has quit (Ping timeout: 264 seconds)
[09:48:43] SteveGoodey (SteveGoodey!~steve@host86-140-98-12.range86-140.btcentralplus.com) has quit (Quit: Konversation terminated!)
[09:49:55] GreyFoxx (GreyFoxx!~greg@out.of.phaze.org) has joined #mythtv
[10:12:56] IReboot (IReboot!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has quit (Remote host closed the connection)
[10:16:30] IReboot (IReboot!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has joined #mythtv
[10:29:33] SteveGoodey (SteveGoodey!~steve@host86-140-98-12.range86-140.btcentralplus.com) has joined #mythtv
[11:11:23] joki (joki!~joki@p54860A68.dip0.t-ipconnect.de) has quit (Ping timeout: 252 seconds)
[11:15:24] map7 (map7!~map7@ppp118-209-121-162.lns20.mel4.internode.on.net) has joined #mythtv
[11:16:17] joki (joki!~joki@p54865E5E.dip0.t-ipconnect.de) has joined #mythtv
[11:46:53] map7 (map7!~map7@ppp118-209-121-162.lns20.mel4.internode.on.net) has quit (Quit: Leaving)
[12:01:14] SteveGoodey (SteveGoodey!~steve@host86-140-98-12.range86-140.btcentralplus.com) has quit (Quit: Konversation terminated!)
[13:25:49] danielk22 (danielk22!~danielk@exchange.wgen.net) has joined #mythtv
[13:37:15] jpharvey (jpharvey!~jpharvey@host86-136-219-238.range86-136.btcentralplus.com) has quit (Remote host closed the connection)
[13:53:14] Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv
[14:28:59] gigem: Hey, maybe I do know something about recording priorities and how the scheduler uses them after all. Whodathunkit!
[14:29:27] gigem: skd5aner: It's commit SHA:14aa7077 .
[14:50:03] gigem: Is anyone still experiencing moderate to long place times in scheduling? I have a test patch which might help some if you have dvb cards and use virtual tuners.
[14:58:00] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 252 seconds)
[15:09:01] wilmoore-misc (wilmoore-misc!~wilmoore@c-67-190-17-108.hsd1.co.comcast.net) has quit (Remote host closed the connection)
[15:38:46] wilmoore-misc (wilmoore-misc!~wilmoore@vlandnat.mystrotv.com) has joined #mythtv
[15:39:07] Chutt (Chutt!~ijr@cpe-76-190-199-73.neo.res.rr.com) has joined #mythtv
[15:42:21] SteveGoodey (SteveGoodey!~steve@host86-140-98-12.range86-140.btcentralplus.com) has joined #mythtv
[15:49:42] memoryguy (memoryguy!~androirc@199.119.232.227) has joined #mythtv
[15:50:34] memoryguy (memoryguy!~androirc@199.119.232.227) has quit (Client Quit)
[15:51:09] memoryguy (memoryguy!~androirc@199.119.232.227) has joined #mythtv
[15:56:10] FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has quit (Quit: FabriceMG)
[15:58:31] stichnot (stichnot!~stichnot@32.174.89.162) has joined #mythtv
[15:58:31] stichnot (stichnot!~stichnot@32.174.89.162) has quit (Changing host)
[15:58:31] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[16:07:04] memoryguy (memoryguy!~androirc@199.119.232.227) has quit (Ping timeout: 276 seconds)
[16:45:50] stuartm: gigem: what's considered long?
[16:52:12] knightr (knightr!~knightr@69-165-170-178.dsl.teksavvy.com) has joined #mythtv
[16:52:12] knightr (knightr!~knightr@69-165-170-178.dsl.teksavvy.com) has quit (Changing host)
[16:52:12] knightr (knightr!~knightr@mythtv/developer/knightr) has joined #mythtv
[17:01:45] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 252 seconds)
[17:22:54] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[17:32:04] Oxyz (Oxyz!~Oxyz@213-65-197-142-no98.tbcn.telia.com) has joined #mythtv
[17:36:57] gigem: stuartm: Anything longer than you'd like it to be! :) I saw a 20% drop in place time (~0.58s to ~0.47s), but those times are too short to draw any conclusions. I have no idea how well, or even if, it will scale to larger times.
[17:59:06] Oxyz (Oxyz!~Oxyz@213-65-197-142-no98.tbcn.telia.com) has quit (Quit: Leaving.)
[18:02:39] Oxyz (Oxyz!~Oxyz@213-65-197-142-no98.tbcn.telia.com) has joined #mythtv
[18:11:53] stuartm: varies between 0.79 and 0.59 here, never quite consistent enough to really identify a drop as small as 20%, it's fast enough for me but in terms of UI responsiveness it could always be faster
[18:13:51] stuartm: and by that I mean, the time between a user hitting 'record' and the guide updating to show that it will (or will not) be recorded
[18:23:59] tonsofpcs: stuartm: it does, that original airdate is 4 months ago. I have another show that always does this (nightly news) that has an original air date of when the news first aired on that station at that hour. That said, if new=true, originalairdate shouldn't matter per SD's forums describing the schema
[18:27:11] gigem: stuartm: http://pastebin.com/AjUV9mWJ . It adds mplexid to RecordingInfo (only for the scheduler) instead of querying for it everytime.
[18:30:33] coling (coling!~colin@cpc7-sgyl36-2-0-cust267.18-2.cable.virginmedia.com) has quit (Quit: leaving)
[18:38:57] stuartm: gigem: related to my chanum vs chanid issue last week I was thinking about rounding out ChannelInfo (did some work on this last year) and re-factoring pretty much everywhere to use it, would it make sense to have RecordingInfo create a ChannelInfo object and store mplexid etc there?
[18:40:00] stuartm: it means adding some indirection, e.g. RecordingInfo->ChannelInfo->mplexid but it would reduce the number of classes storing the same info
[18:57:28] gigem: stuartm: I've actually been contemplating something related for ProgramInfo, but even more grandiose. That is to ChanelInfo, EpisodeInfo (title, subtitle, decription, etc.), WhateverInfo, etc. I don't care for the indirection part, though, and it very recently occurred to me to have ProgramInfo multiply inherit from whatever other *Infos makes sense. It's not derived from QObject, so it might just work.
[19:04:43] dekarl1 is now known as dekarl
[19:10:57] dekarl: gigem: so subtitle gets replaced by EpisodeInfo->title and MoveInfo->tagline? ;)
[19:15:35] ctmjr (ctmjr!~chuck@pdpc/supporter/active/ctmjr) has joined #mythtv
[19:15:47] ctmjr (ctmjr!~chuck@pdpc/supporter/active/ctmjr) has left #mythtv ("Leaving")
[19:20:44] peper03 (peper03!~peper03@port-92-203-96-89.dynamic.qsc.de) has joined #mythtv
[19:29:22] stuartm: gigem: could work :)
[19:29:31] len (len!~quassel@75-161-175-43.mpls.qwest.net) has joined #mythtv
[19:31:08] gigem: dekarl: Yeah, something like that. I hadn't really thought it all through yet.
[19:36:00] sl1ce_1g (sl1ce_1g!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has quit (Quit: Konversation terminated!)
[19:38:23] peper03: I think I have a working patch now for #9429 (although it needs a bit of a tidying up) that seems to handle every case (as far as I can tell). The handling of audio/subtitle streams in libdvdnav is just broken in so many places, it's a wonder it ever works right at all – fields and parameters called 'logical' that are really 'physical', using physical stream ids as indices into a table that maps logical streams *to* physical streams.
[19:38:23] ** MythLogBot http://code.mythtv.org/trac/ticket/9429 **
[19:38:58] coling (coling!~colin@cpc7-sgyl36-2-0-cust267.18-2.cable.virginmedia.com) has joined #mythtv
[19:39:16] peper03: All of that code really needs re-writing and fixing but there's not much point doing that downstream and upstream seems to have died a death...
[19:41:15] peper03: My patch adds one line to libdvdnav to give me access to the physical subpicture stream that libdvdnav is so keen on hiding and mangling but I can't see any other way round it.
[19:41:26] Oxyz (Oxyz!~Oxyz@213-65-197-142-no98.tbcn.telia.com) has quit (Quit: Leaving.)
[19:43:19] kurre2 (kurre2!~tomimo@xdsl-83-150-88-111.nebulazone.fi) has quit (Ping timeout: 246 seconds)
[19:43:23] len (len!~quassel@75-161-175-43.mpls.qwest.net) has quit (Read error: Connection reset by peer)
[19:44:20] paul-h (paul-h!~Paul@94.13.117.6) has joined #mythtv
[20:01:21] kurre2 (kurre2!~tomimo@xdsl-83-150-88-111.nebulazone.fi) has joined #mythtv
[20:05:24] len (len!~quassel@75-161-175-43.mpls.qwest.net) has joined #mythtv
[20:08:55] Cougar (Cougar!~cougar@2a03:5880:104:10:55f4:f531:3689:ebbb) has quit (Ping timeout: 264 seconds)
[20:20:30] jpharvey (jpharvey!~jpharvey@host86-136-219-238.range86-136.btcentralplus.com) has joined #mythtv
[20:20:38] dekarl: gigem: I'm throwing ideas back and forth in my head and always end up with something like "you can't make something from nothing" and I envy your nice SD data. It gets complicated once you leave the "simple US tv series domain" and get series subtitle, season specific series titles and episode subtitles. (likely its as complicated over their but the complexity doesn't make it over here)
[20:21:46] Cougar (Cougar!~cougar@2a03:5880:104:10:a157:71d6:71c0:3d18) has joined #mythtv
[20:26:06] peper03: danielk22: Should the second 'if' here: https://github.com/MythTV/mythtv/blob/master/ . . . se.cpp#L1056 be combined with the first? Doesn't the language index field mean 'the nth stream in a given language'?
[20:26:51] peper03: If so, that second if will cause the loop to end as soon as you match the nth stream in any language, whether it's the language you were looking for or not.
[20:29:59] sl1ce (sl1ce!~johnathan@pool-100-0-73-123.bstnma.fios.verizon.net) has joined #mythtv
[20:38:13] natanojl: peper03: Yeah, I think I noticed that bug a while back when debugging #9429. It's correct in AvFormatDecoder::AutoSelectAudioTrack https://github.com/MythTV/mythtv/blob/master/ . . . er.cpp#L4124
[20:38:13] ** MythLogBot http://code.mythtv.org/trac/ticket/9429 **
[20:42:02] peper03: natanojl: Ah, yes. Good. So it looks like doing the same for subtitles is right too. It certainly caused the wrong subtitle track to be selected sometimes but I wanted to make sure that changing it wouldn't break some other scenario.
[20:46:01] peper03: natanojl: Your patch for 9429 worked well for the Lord of the Rings sample, where the tracks to be filtered were at the end of the list but tracks hidden in the middle caused problems. I think that's when all the libdvdnav problems bubble to the surface.
[20:49:24] peper03: Among other things, as we can find out which tracks are mapped, I've added code to add all the valid subtitle tracks, even those that haven't yet been reported by ffmpeg. Otherwise you often can't select a language until the first packet has been seen, which means you miss that first subtitle.
[20:50:35] natanojl: peper03: Sounds good.
[20:51:04] peper03: It seems to have the nice effect on that LotR sample of automatically enabling the subtitle language based on which flag was chosen right at the beginning.
[20:51:50] danielk22: peper03: It looks like a bug to me. But I haven't looked closely enough to verify the meaning of language_index.
[20:56:56] Oxyz (Oxyz!~Oxyz@213-65-197-142-no98.tbcn.telia.com) has joined #mythtv
[21:00:04] Oxyz (Oxyz!~Oxyz@213-65-197-142-no98.tbcn.telia.com) has quit (Client Quit)
[21:02:27] gigem: dekarl: I can empathize with you. I was here in the pre-DD/SD days when we had to use scrapers, so I know what it's like.
[21:09:09] Oxyz (Oxyz!~Oxyz@213-65-197-142-no98.tbcn.telia.com) has joined #mythtv
[21:10:43] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Read error: Operation timed out)
[21:13:51] Oxyz (Oxyz!~Oxyz@213-65-197-142-no98.tbcn.telia.com) has quit (Ping timeout: 258 seconds)
[21:14:38] rsiebert (rsiebert!~quassel@g225063108.adsl.alicedsl.de) has joined #mythtv
[21:14:49] danielk22 (danielk22!~danielk@exchange.wgen.net) has left #mythtv ()
[21:15:01] rsiebert_ (rsiebert_!~quassel@g225058007.adsl.alicedsl.de) has quit (Ping timeout: 246 seconds)
[21:17:28] paul-h (paul-h!~Paul@94.13.117.6) has quit (Quit: Konversation terminated!)
[21:33:41] SteveGoodey (SteveGoodey!~steve@host86-140-98-12.range86-140.btcentralplus.com) has quit (Quit: Konversation terminated!)
[21:46:57] Jordack (Jordack!~jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit ()
[22:07:26] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya)
[22:11:58] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[22:19:46] Mousey (Mousey!~r0dent_@ross154.net) has joined #mythtv
[22:20:17] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya)
[22:42:20] wahrhaft (wahrhaft!~quassel@cpe-24-210-69-143.columbus.res.rr.com) has quit (Remote host closed the connection)
[23:11:53] peper03 (peper03!~peper03@port-92-203-96-89.dynamic.qsc.de) has quit (Quit: Konversation terminated!)
[23:46:10] jya (jya!~jyavenard@CPE-120-148-103-15.bjzv2.vic.bigpond.net.au) has joined #mythtv
[23:46:10] jya (jya!~jyavenard@CPE-120-148-103-15.bjzv2.vic.bigpond.net.au) has quit (Changing host)
[23:46:10] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[23:47:12] stichnot (stichnot!~stichnot@67.218.103.231) has joined #mythtv
[23:47:12] stichnot (stichnot!~stichnot@67.218.103.231) has quit (Changing host)
[23:47:12] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[23:47:20] jya: danielk221: not sure if you've noticed, but I've re-done the safe_read for the streamingringbuffer class. Everything works okay now...
[23:48:23] jya: http://code.mythtv.org/trac/changeset/8b8ec72 . . . fefb4/mythtv
[23:52:28] jya: I'm now trying to identiffy a crash that occurs from time to time with AirPlay when a new client comes in, I disconnect the existing client. The socket->close() called sometimes crashes here. I remember your point about making sure everything is done in the same thread. So I'd like to add debugging symbols that display which thread a socket is created and in which thread a socket is deleted… How could I go about that?
[23:52:51] jya: to me the socket is created by the airplay running thread, and deleted in that same thread...
[23:53:01] jya: but maybe I've missed something

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