MythLogBot@irc.freenode.net :: #mythtv

Daily chat history

Current users (84):

aloril, amejia, Anssi, anykey_, brfransen, brtb, CaCtus491, Captain_Murdoch, cattelan_away, Chutt, clever, Cougar, damaltor, danielk22, David_Mi1ler, dblain, dekarl, dinamic|screen, ElmerFudd, foobum, foxbuntu, frankster, ghoti, gigem_, gregL, GreyFoxx, highzeth, idl0r, J-e-f-f-A, jams, jarle, jcarlos, joe____, joki, jpabq, jstenback, jwhite, kc, knightr, kurre2, kwmonroe, laga, mag0o, markcerv_, MaverickTech, mike|2, mrand, mrec, MythBuild, MythLogBot, mzanetti, peitolm, Peps, petefunk, pheld, poptix, purserj, rsiebert_, seld, Sharky112065, Slasher`, SmallR2002, sphery, sraue, stichnot_, stuarta, superm1, sutula, taylorr, tgm4883, ThisNewGuy, tomimo, tris, Unhelpful, vallor, Vernon_at_work, wagnerrp, wahrhaft, wseltzer, xavierh, XDS2010_, yb0t, zombor, _charly_
Saturday, June 2nd, 2012, 00:11 UTC
[00:11:07] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 260 seconds)
[00:16:26] kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has quit (Quit: kormoc)
[01:31:28] stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has joined #mythtv
[01:38:22] SmallR2002 (SmallR2002!~quassel@c-98-253-173-240.hsd1.il.comcast.net) has joined #mythtv
[01:50:50] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Remote host closed the connection)
[01:55:17] dekarl1 (dekarl1!~dekarl@p4FCEFCA8.dip.t-dialin.net) has joined #mythtv
[01:57:34] dekarl (dekarl!~dekarl@p4FCEFF2C.dip.t-dialin.net) has quit (Ping timeout: 265 seconds)
[02:13:26] gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has quit (Read error: Connection reset by peer)
[02:16:13] squish102 (squish102!4584c3c5@gateway/web/freenode/ip.69.132.195.197) has joined #mythtv
[02:16:29] squish102 (squish102!4584c3c5@gateway/web/freenode/ip.69.132.195.197) has left #mythtv ()
[02:30:25] gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has joined #mythtv
[02:33:42] stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has quit (Remote host closed the connection)
[02:48:13] kc (kc!~Casper@unaffiliated/kc) has joined #mythtv
[02:59:41] Captain_Murdoch: rhpot1991, no, I haven't tested with anything that powerful. my dev VM where I do most testing is running on a 2.6Ghz Core Duo. Also do some work on my Cure 2 laptop but haven't made notice of res/bitrate vs cpu usage since I was mainly testing features and not speed.
[03:02:27] stearns (stearns!~stearns@076-076-148-019.pdx.net) has joined #mythtv
[03:02:33] stearns (stearns!~stearns@076-076-148-019.pdx.net) has left #mythtv ()
[03:13:56] jya_: Captain_Murdoch: any particular reason you use a 10s segment and not something smaller? would greatly speed up playback starting time
[03:14:55] jya_: that's next on my TODO's list ; find out exactly what airvideo is doing.. cause whatever they are doing is working great
[03:16:12] rhpot1991: jya_: I was under the impression that was in the specs
[03:16:33] jya_: there's nothing setting what the size of a segment should be.
[03:19:18] rhpot1991: Captain_Murdoch: how would one force the transcoding to happen on a 2nd backend, point at that backend when initiating the call and nfs mount the MBE's data?
[03:19:32] jya_: in fact the segment size defined in the playlist header, is only the maximum segment size. each individual segment could have a varying duration, provided their length is less than the maximum defined
[03:20:04] rhpot1991: it doesn't seem to see the recordings via storage groups so I get a 404 when trying to create the stream that way without nfs
[03:20:19] jya_: having said that, I've seen streams here where each individual segment vary in size from 5 to 12s, and the maximum was set to 4.
[03:40:49] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[04:08:50] tomimo (tomimo!~kurre@xdsl-83-150-88-111.nebulazone.fi) has quit (Ping timeout: 252 seconds)
[04:08:54] kurre2 (kurre2!~tomimo@xdsl-83-150-88-111.nebulazone.fi) has quit (Ping timeout: 245 seconds)
[04:17:00] jya_: dekarl1: I too got no audio with Al Jazeera :(
[04:17:31] jya_: going to check if it's related to the ffmpeg resync or if it's the media itself.
[04:34:53] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[05:20:33] jya_: danielk22: I'm still seeing the issue where in liveTV you can't change to another channel. Well you can change channel, but when you validate you go back to the channel you were watching earlier
[05:21:51] jya_: this happens when in liveTV I press Record… after than, (sometimes, not always) you can't change anymore
[05:35:18] dekarl1: jya_, I looked at the recorded program and the audio PID is not there. As the stream type is not decoded to text my first guess was the recorder might not be recognizing that its an interesting PID. I'm not sure if the recorder takes every PID in the PMT or just some.
[05:35:22] dekarl1 is now known as dekarl
[05:36:14] jya_: from what danielk22 was saying a little while ago when I asked, the player/recorder looks for a specifc pid (0 for video etc)
[05:38:45] dekarl: ahh, it should look at PID 0 for the PAT, find the program_id there (or just take the single program). Now that it knows the PID of the PMT it can look into that and see which PIDs belogn to the service
[05:38:58] dekarl: http://paste.ubuntu.com/1018724/ <- the PAT/PMT
[05:39:05] jya_: the stream recorded is 100% whatever al jazeera is broadcasting.. i have reverted back to the 3 months old ffmep resync, and the issue occurs on all of the version of ffmpeg resync. except the old ffmpeg saw AAC 0 channels
[05:39:37] dekarl: I think this is describes the audio PID: Stream #0 pid(0x102) type(0x15 unknown)
[05:39:37] ** MythLogBot http://code.mythtv.org/trac/ticket/0 **
[05:40:09] jya_: it still doesn't show the audio stream to start with
[05:40:26] jya_: have you tried playing the stream on an iphone/ipad?
[05:40:47] dekarl: not yet
[05:44:04] jya_: let me try
[05:44:44] jya_: yep work fine
[05:45:03] jya_: i'm going to record a stream , and try with ffplay
[05:45:56] jya_: ah
[05:46:03] jya_: i have audio now on myth
[05:46:19] jya_: could it be just a temporary issue with aljazeera
[05:47:26] dekarl: maybe, might be an idea for extending the checker to look for video/audio on TV services or audio on radio services to decide if a recording is broken
[05:58:38] stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has quit (Ping timeout: 240 seconds)
[06:02:37] dekarl: jya, now I see audio, too. http://paste.ubuntu.com/1019098/
[06:08:19] dekarl: I see that stream_type 0x15 is metadata wrapped in PES packets... with HLS thats likely ID3 tags http://developer.apple.com/library/ios/#docum . . . pec/2/2.html
[06:12:12] jya_: dekarl: yeah… looks like it was a temporary issue with the stream
[06:12:50] dekarl: btw, does the recorder chose the highest bitrate stream first?
[06:13:43] jya_: yes..
[06:13:58] dekarl: very nice (saw some playlist where that wasnt the first one)
[06:14:04] jya_: it goes that way.. retrieve all the stream definition, sort them from high to low
[06:14:40] jya_: then it goes and download 2 segments
[06:15:00] jya_: the first segment is always the highest bitrate one, this allows to measure the speed of your connection
[06:15:29] jya_: then the 2nd segment is from the stream that fits in the measured bandwidth
[06:16:18] jya_: as playback goes, the bandwidth is constantly average, if the average becomes too low, it will switch to a lower bitrate stream
[06:16:26] jya_: it never goes up, just down
[06:17:13] dekarl: ahh, might be another value to feed into the recording quality. number of times it switched down
[06:17:38] jya_: now that is uses the average, prevent switching too often
[06:17:49] stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has joined #mythtv
[06:17:59] jya_: but it mean it could also take too many attempts before it decides to switch down
[06:18:23] jya_: i thought about that, instead of choosing the average since the beginning of streaming
[06:18:31] jya_: could only average the last minute or something
[06:18:44] dekarl: was just thinking of someone pulling in a big mail might temporarily reduce the available bandwidth. so it should not switch on the first hickup
[06:19:11] jya_: dekarl : unless it happens at the beginning , where it would have a big impact on the average
[06:19:13] jya_: it won't
[06:19:31] jya_: but remember that for a live stream, if you wait too long, you won't be able to get the segment
[06:19:42] jya_: aljazeera for example, only provide the last 3 segments
[06:19:53] jya_: after that you can't retrieve it anymore
[06:19:59] dekarl: hmm, now I need to find nasatv guide data. its not contained in the tpg xmltv file anymore
[06:20:21] jya_: and aljazeera segment length vary between 6 and 15s
[06:20:56] jya_: actuallly
[06:21:01] jya_: that points to a problem there
[06:21:05] dekarl: sounds like a bug in the wowza streaming server then... not announcing them anymore in the m3u8 sounds fine, but pulling it so quickly sounds like a bad idea for internet streams
[06:21:20] jya_: I refresh the live stream every half maximum segment duration
[06:21:38] jya_: si i refresh every 7s as aljazeera mark them as 15s (was 17s last week)
[06:22:21] jya_: if the segment is less than 7s, i will not refresh the least quickly enough...
[06:22:53] jya_: dekarl: i don't see how that's a bug, this is a live stream… if you don't download them fast enough, sooner or later you will hit a problem, even if they buffered for longer
[06:23:01] jya_: nasa keep 6 segments for example
[06:24:47] jya_: i think at the end of download a segment i should wake up the live updating thread, … would reduce the problem
[06:25:33] dekarl: the segments have different length? like the first is 6s, the seceond 11s and from then on all as 15s? Might be a good idea to fast starting of new viewers, then switch over to the 15s segments.
[06:26:11] jya_: dekarl: it's not something you have control of.. you get what comes to you
[06:26:22] jya_: and every stream is different
[06:26:30] jya_: nasa all segments are exactly 8s
[06:26:42] dekarl: aye, was just thinking about the HLS server side. how to mix quick start of the stream with not to small segments...
[06:26:45] jya_: France24 they are 18s
[06:27:01] jya_: dekarl: for the server, I would make all segments 4s max
[06:27:03] dekarl: just make the first few segments smaller, so they are encoded/transmitted faster
[06:27:11] jya_: totally agree
[06:29:04] dekarl: for a live stream one could make 15s segments and 15/2s segments and 15/4 segments. get each client a dynamic playlist that gives it 1 or 2 "quarter segments", maybe 1 "half segment" and from the on full segments. <- but thats only for mythtv restreaming livetv to multiple clients, a bit outside of the target corridor :)
[06:41:48] jya_: dekarl: that would be outside the ietf spec
[06:42:12] jya_: each stream must have exactly the same segment of the same duration just at different bitrates
[06:42:37] jya_: so you can switch live to a different stream and not be interrupted
[06:42:56] dekarl: I was thinking of 2 sets of premade "on ramp" segments that lead new listeners to the regular segments
[06:43:38] jya_: that's outside the standard
[06:44:29] jya_: you could always do so, because ultimately, you can stuff anything you want in the m3u8 file
[06:44:53] dekarl: the standards says I'm not allowed to customize the playlist for each listener?
[06:45:00] stoffel (stoffel!~quassel@pD9E438A4.dip.t-dialin.net) has joined #mythtv
[06:46:30] dekarl: so I make 16s segments, and for each segment on 8s segment leading up to it, and a 4s segment leading up to that. each session gets its own playlist of the 4s, the 8s and from then on the normal 16s segments. all the same on all bandwidth.
[06:48:49] jya_: no the standard says that any sub-streams should be identical to each other but the bitrate
[06:50:04] dekarl: ok, that could be easily done. (so many ideas, so little time :(
[06:50:58] jya_: i would just make 4s streams and be off with it
[06:57:02] tomimo (tomimo!~kurre@xdsl-83-150-88-111.nebulazone.fi) has joined #mythtv
[06:57:04] kurre2 (kurre2!~tomimo@xdsl-83-150-88-111.nebulazone.fi) has joined #mythtv
[06:57:58] jya_: at the end of the day, the load on the server to download 8s segments ,or twice as many 4s segments would be nearly identical
[07:00:25] dekarl: I think the reason for bigger segments lies in content distribution networks, like amazon s3, which add some latency and charge by transfer and volume. making the segments bigger is a simple way to reduce the costs a bit. (have not done the math for HLS style, but for xmltv guides it makes a difference due to caching strategies)
[07:01:25] dekarl: but I agree, serving up some static files is not going to kill any decent webserver based on the segment size
[07:05:07] sensesay is now known as sensesay[A]
[07:05:07] ** sensesay[A] is now away – Reason : ZZZZZZZZZZZZZZZZZZZzzzzzzzzzzzzzzzz **
[07:19:52] CaCtus491 (CaCtus491!~Kent@123-243-197-152.static.tpgi.com.au) has quit (Ping timeout: 252 seconds)
[07:24:17] rsiebert_ (rsiebert_!~quassel@g229053130.adsl.alicedsl.de) has joined #mythtv
[07:24:41] rsiebert (rsiebert!~quassel@g226062043.adsl.alicedsl.de) has quit (Ping timeout: 246 seconds)
[07:24:42] sensesay[A] (sensesay[A]!~Sensesay@c-67-185-145-2.hsd1.wa.comcast.net) has quit (Read error: Connection reset by peer)
[07:25:02] sensesay[A] (sensesay[A]!~Sensesay@c-67-185-145-2.hsd1.wa.comcast.net) has joined #mythtv
[08:45:59] stuartm (stuartm!~stuartm@cpc1-derb9-0-0-cust441.8-3.cable.virginmedia.com) has joined #mythtv
[08:45:59] stuartm (stuartm!~stuartm@cpc1-derb9-0-0-cust441.8-3.cable.virginmedia.com) has quit (Changing host)
[08:45:59] stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has joined #mythtv
[09:12:22] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv
[09:27:13] CaCtus491 (CaCtus491!~Kent@123-243-197-152.static.tpgi.com.au) has joined #mythtv
[09:49:29] stoffel (stoffel!~quassel@pD9E438A4.dip.t-dialin.net) has quit (Ping timeout: 244 seconds)
[10:05:02] Guest72996 (Guest72996!~mike@c-98-232-220-158.hsd1.or.comcast.net) has quit (Remote host closed the connection)
[10:05:48] mike|2 (mike|2!~mike@c-98-232-220-158.hsd1.or.comcast.net) has joined #mythtv
[10:26:26] stuartm: I'm not yet admitting defeat, but so far I can't even get ffmpeg to compile on the Pi, if it doesn't run out of memory (which was expected) then gcc just crashes
[10:32:51] stoffel (stoffel!~quassel@pD9E438A4.dip.t-dialin.net) has joined #mythtv
[10:38:33] anykey_ (anykey_!~anykey@46-126-245-147.dynamic.hispeed.ch) has quit (Quit: leaving)
[10:45:37] xavierh (xavierh!~xavier@cpc1-swin3-0-0-cust274.3-1.cable.virginmedia.com) has quit (Read error: Connection reset by peer)
[10:51:12] xavierh (xavierh!~xavier@cpc1-swin3-0-0-cust274.3-1.cable.virginmedia.com) has joined #mythtv
[11:03:45] cocoa117 (cocoa117!~cocoa117@188-222-31-239.zone13.bethere.co.uk) has joined #mythtv
[11:12:40] sensesay[A] (sensesay[A]!~Sensesay@c-67-185-145-2.hsd1.wa.comcast.net) has quit (Ping timeout: 244 seconds)
[11:19:58] sensesay[A] (sensesay[A]!~Sensesay@c-67-185-145-2.hsd1.wa.comcast.net) has joined #mythtv
[11:23:53] hashbang (hashbang!~alex@213-152-35-50.dsl.eclipse.net.uk) has joined #mythtv
[11:48:27] coling (coling!~colin@cpc7-sgyl36-2-0-cust267.18-2.cable.virginmedia.com) has quit (Quit: leaving)
[12:25:48] ElmerFudd: stuartm: Trying to compile myth on a raspberry pi? I couldn't compile mythtv on my efika mx smartbook (also arm), which has 512 MB ram. I ended up compiling it on my trimslice with 1 GB, as I'm unfamiliar with setting up cross compilers
[12:27:16] stuartm: yeah, I expected it to be futile, but I had hoped to get further than I did
[12:28:21] ElmerFudd: is there openMAX in mythtv now ? – there is currently no XVideo support on the Pi, I think openMAX is the only way to go with video acceleration
[12:28:28] stuartm: I'll end up cross compiling but since I've never done it before I'll have to spend a lot of time getting up to speed, which is time I can't spend more productively on writing actual code
[12:28:55] stoffel (stoffel!~quassel@pD9E438A4.dip.t-dialin.net) has quit (Remote host closed the connection)
[12:29:15] stuartm: ElmerFudd: no openMax, not expecting to get video working at all, but I was interested in seeing whether I could actually get the memory requirements of the frontend down low enough for everything else to work
[12:29:17] ElmerFudd: right now I'm using raspbmc as a frontend on my Pi, but it is less than ideal. I'd really like a real frontend running on raspbian :)
[12:29:36] ElmerFudd: ok
[12:30:51] stuartm: basically it was an exercise in optimisation, even if the mythfrontend which runs on the Pi is limited (very basic theme etc) it might have benefits elsewhere
[12:31:04] stuartm: or it could turn out to be a complete waste of time ... not sure which yet
[12:32:31] ElmerFudd: yeah never hurts to test out code on restrained devices
[12:32:43] stuartm: so far the most fun I've managed to get from the Pi is designing/making a case, even that's a learning exercise as I overtightened a clamp this morning and cracked my first attempt
[12:34:30] stuartm: does the Pi need a case? Well no, but I felt like doing something creative that didn't involve sitting in front of a screen
[13:13:15] stichnot: stuartm: you haven't cut 0.25.1 yet, have you? What's the expected timeline?
[13:13:16] jya_: stichnot: can you confirm that mythtranscode works again with the latest ffmpeg resync ?
[13:13:47] stuartm: stichnot: sometime this weekend whenever I'm in the mood
[13:14:00] stoffel (stoffel!~quassel@pD9E438A4.dip.t-dialin.net) has joined #mythtv
[13:14:53] jya_: i'd like to backport the IPTV fixes ; I need to get some confirmation that it's working fine… no one has got back to me yet
[13:15:59] stichnot: stuartm: ok, I think I'll go ahead and backport the 10678 fix into 0.25-fixes since it seems to work on the half-dozen teletext samples I have (and also doesn't seem to break the interactive teletext menu stuff)
[13:16:44] anykey_ (anykey_!~anykey@46-126-245-147.dynamic.hispeed.ch) has joined #mythtv
[13:16:48] stichnot: jya_: I can try mythtranscode, but I haven't been in the habit of running it for the last ~2 years so if it breaks I won't know if it's new breakage
[13:17:05] jya_: oops sorry, I meant mythcommflag
[13:17:15] jya_: whatever broke with the removal of lowres decoding
[13:17:24] jya_: now that it's back wanted to check
[13:17:24] stichnot: ok
[13:17:53] jya_: i've reversed danielk22 changes that disabled the use of lowres
[13:19:39] stichnot: jya_: several shows recorded last night with the latest Master and commflag worked reasonably
[13:19:50] jya_: excellent
[13:19:56] stichnot: I think the high-order bit here is that it didn't crash :)
[13:20:35] stichnot: also, I tried adding the lowres flag to cutlist editor thumbnail generation, but it didn't seem to change performance much if at all :(
[13:24:25] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[13:26:06] stichnot: too bad "git diff" isn't smarter about changes that are just from indenting a block of code
[13:28:41] stuartm: git diff -w ?
[13:38:11] stichnot: I guess I mean the patch format, not specifically "git diff". My latest commit looks much more complicated than it actually is
[13:50:53] Sharky112065 (Sharky112065!~Sharky112@c-67-170-55-74.hsd1.wa.comcast.net) has quit (Ping timeout: 245 seconds)
[13:51:00] Sharky112065 (Sharky112065!~Sharky112@c-67-170-55-74.hsd1.wa.comcast.net) has joined #mythtv
[13:54:01] stuartm: ah
[13:59:50] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[14:40:53] danielk22: stichnot: you can use "git add -p files" to split a patch into whitespace and functional bits.
[14:42:34] stuartm: an option to ignore whitespace changes when adding would be nice
[14:42:45] stuartm: if wishes were stars and all that ...
[14:44:24] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[15:03:26] stuartm: danielk22: do you intend using ReferenceCounter for MythImage?
[15:46:01] dj_who (dj_who!~djwho@cha19.neoplus.adsl.tpnet.pl) has joined #mythtv
[15:46:17] dj_who (dj_who!~djwho@cha19.neoplus.adsl.tpnet.pl) has left #mythtv ("JOIN #mythtv-users")
[16:00:27] gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has quit (Read error: Connection reset by peer)
[16:08:34] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[16:10:36] gigem_ (gigem_!~david@mythtv/developer/gigem) has joined #mythtv
[16:11:42] gigem (gigem!~david@mythtv/developer/gigem) has quit (Ping timeout: 244 seconds)
[16:13:54] joki- (joki-!~joki@p5486304D.dip.t-dialin.net) has joined #mythtv
[16:14:02] joki (joki!~joki@p548656FB.dip.t-dialin.net) has quit (Ping timeout: 265 seconds)
[16:14:02] joki- is now known as joki
[16:16:53] gregL (gregL!~greg@cpe-74-76-125-87.nycap.res.rr.com) has joined #mythtv
[16:17:41] randomuser (randomuser!~pete@fedora/immanetize) has joined #mythtv
[16:57:22] stoffel (stoffel!~quassel@pD9E438A4.dip.t-dialin.net) has quit (Read error: Connection reset by peer)
[16:58:42] stoffel (stoffel!~quassel@pD9E438A4.dip.t-dialin.net) has joined #mythtv
[17:08:31] stoffel (stoffel!~quassel@pD9E438A4.dip.t-dialin.net) has quit (Ping timeout: 256 seconds)
[17:23:23] kwmonroe (kwmonroe!~kwmonroe@32.97.110.58) has quit (Ping timeout: 245 seconds)
[17:32:03] kwmonroe (kwmonroe!~kwmonroe@32.97.110.58) has joined #mythtv
[17:40:30] amejia (amejia!~andres@xbmc/staff/amejia) has quit (Quit: Konversation terminated!)
[17:43:13] amejia (amejia!~andres@xbmc/staff/amejia) has joined #mythtv
[18:24:04] stoffel (stoffel!~quassel@217.228.56.164) has joined #mythtv
[19:10:42] cocoa117 (cocoa117!~cocoa117@188-222-31-239.zone13.bethere.co.uk) has quit (Quit: Leaving)
[19:25:37] stoffel (stoffel!~quassel@217.228.56.164) has quit (Ping timeout: 252 seconds)
[19:42:19] danielk22: stuartm: Yes, but that is probably the most complex use of reference counting in MythTV so it will be the last converted.
[19:43:39] stuartm: is playback broken for anyone else in trunk? Seems to play half a second of audio then bails with 'Failed to initialise A/V sync' (using vdpau)
[19:44:01] stuartm: "Object deleted with non-zero reference count!" have anything to do with it?
[19:44:25] stuartm: hmm, maybe this actually – "VidOutVDPAU: IsErrored() in DrawSlice"
[19:48:21] sensesay[A] (sensesay[A]!~Sensesay@c-67-185-145-2.hsd1.wa.comcast.net) has quit (Ping timeout: 252 seconds)
[20:13:33] randomuser (randomuser!~pete@fedora/immanetize) has left #mythtv ("Leaving")
[20:21:02] danielk22: stuartm: The reference counting error is something I need to look at, but I think it is more likely that you either have an nvidia driver + lib mismatch or it's due to one of the recent ffmpeg merges.
[20:25:29] stuartm: danielk22: yeah, managed to fix the error I was seeing and I've no reason to believe it was related to your changes
[20:37:54] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[21:08:17] amejia_ (amejia_!~andres@129.174.97.130) has joined #mythtv
[21:08:17] amejia_ (amejia_!~andres@xbmc/staff/amejia) has joined #mythtv
[21:08:17] amejia_ (amejia_!~andres@129.174.97.130) has quit (Changing host)
[21:11:22] andreax (andreax!~andreaz@p54BF39C6.dip.t-dialin.net) has joined #mythtv
[21:15:04] ocrateb (ocrateb!~ocrateb@unaffiliated/ocrateb) has joined #mythtv
[21:26:36] stuartm: sphery: I'm still not clear why the SD stuff can't just use the same behaviour as the xmltv parser which never wipes the program table, it just replaces programs within it
[21:27:07] sphery: it could if someone wrote it
[21:27:10] stuartm: of course you'd get that benefit automatically if we just dropped the DD parser and used the xmltv code for everything
[21:27:12] antgel (antgel!~topdog@bzq-82-81-14-39.red.bezeqint.net) has quit (Read error: Operation timed out)
[21:27:19] sphery: there is that, too
[21:27:28] sphery: and a much easier approach
[21:28:57] sphery: I have to admit that I haven't been super motivated to work on fixing up the --dd-grab-all/Schedules Direct grabbing stuff because both work fine for me (and I lose current listings for just seconds, so the chances of an issue are exceedingly small)
[21:29:20] sphery: actually, may be less than 1s that I lose current listings
[21:30:18] sphery: I do like the idea of using tv_grab_na_dd--as long as we ensure we still get the programid/seriesid from it
[21:30:21] SteveGoodey (SteveGoodey!~steve@host86-160-43-123.range86-160.btcentralplus.com) has quit (Remote host closed the connection)
[21:31:08] stuartm: iirc the data is there, we might even parse it out, but I'd need to check
[21:31:27] sphery: yeah, we currently don't use any reported programid/seriesid for xmltv data, but we could
[21:31:59] sphery: (and doing so would be much less work than rewriting/optimizing the existing DD grabber)
[21:32:34] stuartm: there are some things we do differently in the SD parser which I'd need to check and implement, but it really shouldn't be too much work, and if we get the apiconfig stuff done then users will even have a nice ui for entering their subscription details
[21:32:52] hashbang (hashbang!~alex@213-152-35-50.dsl.eclipse.net.uk) has quit (Quit: Leaving.)
[21:33:59] sphery: http://code.mythtv.org/trac/ticket/6478 tried to modify DD processing do the "replace instead of delete/insert" approach, but it seemed too big/invasive
[21:34:07] sphery: switching to xmltv parser makes far more sense
[21:36:02] sphery: of course, users will love us for adding a new dependency for North American users :)
[21:36:16] stuartm: I'll take a look at adding series/programid parsing, and whatever else is currently missing e.g. I think the SD parser is inserting more cast info
[21:36:49] sphery: need a grab of some xmltv data from tv_grab_na_dd to see what's there... I'll boot up my dev box and pull some
[21:37:22] stuartm: sphery: given the shrinking number of devs, having just one parser/code path for mfdb will hopefully mean it gets more attention
[21:37:27] sphery: yes
[21:37:47] sphery: and would mean we could start adding support for "the rest of the data" to xmltv--i.e. additional cast/crew/genre stuff
[21:37:51] stuartm: sphery: if there's anything lacking we can go upstream and get it added to the grabber
[21:39:34] stuartm: actually it might be the extended genre stuff that we don't parse, I think we just take the first and ignore the rest, but I'm really just guessing until I look at the code again and refresh my memory
[21:40:08] stuartm: we do handle cast/crew stuff from xmltv (I have rules setup on actors/directors)
[21:40:22] sphery: yeah, and, really, even though we pull the rest for SD, we don't really use it
[21:41:01] sphery: hehe: NOTE: Your subscription will expire: 2013-06–21T22:20:14Z
[21:41:22] sphery: since the end of the world is 6 months before that, I don't think I have anything to worry about
[21:41:45] sphery: (not to mention their definition of soon is very different from mine)
[21:53:37] jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_)
[21:54:26] jya_ (jya_!~jyavenard@120.148.99.165) has joined #mythtv
[21:54:26] jya_ (jya_!~jyavenard@120.148.99.165) has quit (Changing host)
[21:54:26] jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv
[22:20:43] natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 244 seconds)
[22:30:03] stuartm: sphery: it's clearly only checking the date and not the year
[22:49:38] megadeth (megadeth!rot@106.51.5.165) has quit (Ping timeout: 245 seconds)
[22:52:16] andreax (andreax!~andreaz@p54BF39C6.dip.t-dialin.net) has quit (Read error: Connection reset by peer)
[23:04:54] cesman (cesman!~cesman@pool-108-0-54-134.lsanca.fios.verizon.net) has joined #mythtv
[23:04:54] cesman (cesman!~cesman@pdpc/supporter/professional/cesman) has joined #mythtv
[23:04:54] cesman (cesman!~cesman@pool-108-0-54-134.lsanca.fios.verizon.net) has quit (Changing host)
[23:08:44] amejia_ (amejia_!~andres@129.174.97.130) has joined #mythtv
[23:08:44] amejia_ (amejia_!~andres@xbmc/staff/amejia) has joined #mythtv
[23:08:44] amejia_ (amejia_!~andres@129.174.97.130) has quit (Changing host)
[23:30:10] Sharky112065 (Sharky112065!~Sharky112@c-67-170-55-74.hsd1.wa.comcast.net) has quit (Quit: “The only way to have a friend is to be one.” ― Ralph Waldo Emerson)
[23:33:58] xris (xris!~xris@mythtv/developer/xris) has quit (Read error: Operation timed out)
[23:37:01] Sharky112065 (Sharky112065!~Sharky112@c-67-170-55-74.hsd1.wa.comcast.net) has joined #mythtv
[23:40:25] ocrateb (ocrateb!~ocrateb@unaffiliated/ocrateb) has quit (Remote host closed the connection)

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