:: #mythtv

Daily chat history

Current users (85):

aca_, aloril, amessina, Anssi, Beirdo_, bobweaver, brfransen, Captain_Murdoch, Chutt, clever, coling, Cougar, danielk22, danielk222, dblain, dekarl, ElmerFudd, fetzerch, foobum, foxbuntu, gary_buhrmaster, ghoti, Gibby, gigem, gregL, GreyFoxx, J-e-f-f-A, jams, jarle, jarryd, jhall_, jheizer, joe__, joki, jpabq, jpabq_, jpharvey, jst, jwhite, jya, jya_, knightr, kormoc, krumer, KungFuJesus, kurre2, kwmonroe, laga, len, MavT, Merlin83b, moparisthebest_, mrand1, MythBuild, MythLogBot, neufeld, poptix, purserj, rhpot1991, rsiebert, Seeker`, seld, Sharky112065, skidaddle, sl1ce, SmallR2002, sp00ge, sphery, sraue, stichnot, stuarta, stuartm, superm1, taylorr, tgm4883, Tobbe5178, toeb, tonsofpcs, wagnerrp, wahrhaft, wolfgang2, XDS2010, xris, _charly_, _nyloc_
Sunday, June 2nd, 2013, 00:32 UTC
[00:32:19] SteveGoodey (SteveGoodey! has joined #mythtv
[01:09:30] jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv
[01:13:09] jya_: hello everyone… after crazy work weeks.. finally a day I can work on myth
[01:15:47] jya_: so what have I missed in those past few weeks?
[01:25:57] SteveGoodey (SteveGoodey! has quit (Quit: Konversation terminated!)
[01:51:05] jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_)
[02:09:56] jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv
[02:16:01] jhall_ (jhall_!~jhall@2001:468:d01:9c:226:b9ff:fe2d:482e) has joined #mythtv
[02:23:37] _nyloc_ (_nyloc_! has joined #mythtv
[02:27:45] nyloc (nyloc! has quit (Ping timeout: 248 seconds)
[02:32:04] neufeld is now known as neufeld_AFK
[02:37:05] jheizer_ (jheizer_! has joined #mythtv
[03:04:14] gigem: jya_: Welcome back. Hmm, the biggest, recent things I can recall are stichnot's XML based OSD menu and a renewed push led by stuartm to fix static analysis bugs.
[03:07:09] jya_: thanks for that… yes, I saw the various commits related to coverity
[03:18:03] joki (joki! has quit (Ping timeout: 245 seconds)
[03:22:55] jheizer_ (jheizer_! has quit (Ping timeout: 256 seconds)
[03:25:24] joki (joki! has joined #mythtv
[03:28:48] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 256 seconds)
[03:30:04] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv
[04:50:09] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 248 seconds)
[04:53:51] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv
[06:10:03] XDS2010 (XDS2010!uid1218@gateway/web/ has quit (*.net *.split)
[06:10:03] brfransen (brfransen!~brfransen@ has quit (*.net *.split)
[06:10:03] Sharky112065 (Sharky112065! has quit (*.net *.split)
[06:10:04] jarryd (jarryd! has quit (*.net *.split)
[06:10:04] tris (tris!tristan@2001:1868:a00a::4) has quit (*.net *.split)
[06:16:37] tris (tris!tristan@2001:1868:a00a::4) has joined #mythtv
[06:17:27] brfransen (brfransen!~brfransen@ has joined #mythtv
[06:18:34] jarryd (jarryd! has joined #mythtv
[06:21:14] danielk22 (danielk22! has joined #mythtv
[06:21:14] Sharky112065 (Sharky112065! has joined #mythtv
[06:22:57] stoffel (stoffel! has joined #mythtv
[06:36:23] danielk22 (danielk22! has quit (*.net *.split)
[06:36:23] Sharky112065 (Sharky112065! has quit (*.net *.split)
[06:42:50] Tobbe5178 (Tobbe5178! has joined #mythtv
[06:49:18] danielk22 (danielk22! has joined #mythtv
[06:49:19] Sharky112065 (Sharky112065! has joined #mythtv
[07:02:21] len (len! has quit (Read error: Connection reset by peer)
[07:59:00] sharky-wtf (sharky-wtf! has joined #mythtv
[07:59:33] sharky-wtf is now known as Sharky-112065
[08:01:25] Sharky112065 (Sharky112065! has quit (Ping timeout: 252 seconds)
[08:02:52] Sharky-112065 is now known as Sharky112065
[08:23:21] XDS2010 (XDS2010!uid1218@gateway/web/ has joined #mythtv
[08:27:41] jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_)
[08:29:05] jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv
[08:40:53] stoffel_ (stoffel_! has joined #mythtv
[08:41:13] stoffel (stoffel! has quit (Ping timeout: 246 seconds)
[08:54:27] jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_)
[09:08:10] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!)
[09:12:48] _Dweller (_Dweller! has joined #mythtv
[09:14:29] _Dweller: any tips for writing to a cifs mount? I _think_ that when the share gets busy my writes still succeed but might be taking longer to return, causing my single thread device-read-fd-write loop to spend too long in the write, dropping the signal.
[09:15:27] _Dweller: I figure moving to a threaded write with a write queue, or ringbuffer will help if thats the case, but thought worth asking before I try all that ;p
[09:15:39] jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv
[09:21:47] SteveGoodey (SteveGoodey! has joined #mythtv
[09:22:25] ** _Dweller tries adjusting rsize / wsize on the cifs mount 1st **
[09:26:04] stuartm: cifs is a PITA, if you're not using windows then nfs is much better
[09:26:57] _Dweller: my bulk storage is all over on win.. I could put an nfs server there, but if I can get it working with cifs, it'll be much more useful =)
[09:29:22] _Dweller: at least the pi/hdpvr seems a lot more stable now too =) and google & yahoo have unblocked me today after all the imdb queries I ran yesterday ;p
[09:29:25] stuartm: danielk222: my backend is currently using 743 threads, which seems extremely excessive, I'm unable to get a backtrace to see what the runaway threads are – any ideas?
[09:31:22] stuartm: restarting it and will watch to see if it reoccurs, at which point I'll be able to use gdb et al
[09:32:01] dekarl: _Dweller: have you considered ansynchronus io? e.g. . . . fWrites.html
[09:32:35] _Dweller: dekarl: ooh.. didn't know about that.. having a read =)
[09:32:49] ** _Dweller has been in Java for waaay too long ;p **
[09:34:34] stuartm: danielk222: you might want to review
[09:36:02] stuartm: in particular I'm wondering if there's a way to devise a test for that condition artificially since it would ordinarily be rare
[09:36:51] _Dweller: dekarl: seems simple enough, tho I become responsible for tracking the offset to write at.. I'll see if I can't convert to using that for disk i/o .. I'll leave the socket i/o as straight write since vlc is fine if things go awol
[09:53:22] ephemer0l_ (ephemer0l_!~ephemer0l@ has quit (Quit: No Ping reply in 180 seconds.)
[10:10:06] paul-h (paul-h!~Paul@ has joined #mythtv
[10:27:14] natanojl (natanojl! has joined #mythtv
[10:31:33] jarle (jarle! has quit (Remote host closed the connection)
[10:45:21] stuartm: paul-h: thanks for working on the coverity stuff, for all the stuff that seems trivial or which turns out to be a false positive it does still find some real bugs, so it's worth the effort in the long run
[10:54:11] paul-h: yeah I was sceptical at first but it is finding a few real bugs but they are few and far between
[10:54:32] paul-h: anything that returns Myth back to being more stable can only be a good thing though
[10:54:57] jpharvey (jpharvey! has quit (Ping timeout: 248 seconds)
[10:57:54] paul-h: I thought that Eric guy was really smart finding all those bugs but now I realise he was just copy/pasting stuff from some static analysis tool :)
[11:00:08] IReboot (IReboot! has joined #mythtv
[11:04:39] peper03 (peper03! has joined #mythtv
[11:04:59] stuartm: :)
[11:12:37] jya_: danielk22: your use of rpath breaks compilation for me on my mac with Qt 4.8.3. "ld: unknown option: -rpath=/U"
[11:14:02] jya_: syntax used elsewhere is ,-rpath,PATH
[11:25:49] jya_: hum… with a , instead of a = it doesn't find the library
[12:06:43] stoffel_ (stoffel_! has quit (Ping timeout: 252 seconds)
[12:09:49] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv
[12:32:21] tris (tris!tristan@2001:1868:a00a::4) has quit (Ping timeout: 240 seconds)
[12:43:41] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!)
[12:47:30] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv
[12:49:07] jya_: danielk22: you're there?
[12:50:42] neufeld_AFK is now known as neufeld
[12:53:08] stoffel (stoffel! has joined #mythtv
[13:01:08] stoffel (stoffel! has quit (Ping timeout: 256 seconds)
[13:03:07] danielk222: jya_: hey, so it doesn't like rpath?
[13:03:13] jya_: nope
[13:03:25] jya_: not rpath=
[13:03:28] jya_: rpath, yes
[13:03:47] danielk222: just with a comma rather than = ? let me test that here...
[13:03:52] jya_: but that's not what I was pinging you for.. (for the time being I just removed the running of the test script)
[13:04:19] jya_: well, I did replace it to use a , (that's how all the other rpath are used throughout the code
[13:05:16] jya_: but when I did replace the = with a ,, it failed to run the test script, complaining the libmythbase couldn't be found (I compile in a jail, so nothing is installed at this point)
[13:05:28] jya_: but I wanted your feedback on the HLS recorder
[13:05:34] jya_: so I have something running
[13:05:38] danielk222: cool
[13:06:12] danielk222: Is it in a devel/xxx branch? I'm happy to review and help with any snags.
[13:06:46] jya_: no, it's on my machine :)
[13:07:07] jya_: what I'm noticing is that my hlsstreamhandler is called in two steps
[13:07:44] danielk222: one for the signal monitor and one for the recording ?
[13:07:48] jya_: problem is that it means is I open the HLS url, start downloading
[13:08:02] jya_: (that's in the run)
[13:08:19] jya_: then it's closed, and run is called again: re-doing the whole lot
[13:08:40] jya_: problem is that most HLS stream I have take a good 10–20s to finally get a first HLS segment (10s worth)
[13:08:53] jya_: so that makes it 40s all up..
[13:08:55] danielk222: it is closed? hmm, that shouldn't be happening...
[13:09:00] jya_: fronted usually timeout before that
[13:09:16] jya_: well, I copied your iptvstreamhandler
[13:09:34] jya_: which open the stream in run(), and immediately close it when it exits the loop
[13:10:37] jya_: currently I've duplicated every single class of iptv* (channel, signal monitor, recorder and stream handler)
[13:10:38] danielk222: I think it is the signal monitor that needs changing.. you don't really need to do a full evaluation of the stream or download a whole segment, just see that server is responsive at all.
[13:11:35] jya_: yeah, problem is that the hls ring buffer (which is used) isn't designed like that at all. I open a stream , and close it.. that's about it.. i get no other information in regards to the server being responsive before finishing downloading the first segment
[13:11:46] danielk222: jya: Really only the streamhandler and signalmonitor should need any changing.. but I see the merit in cloning the whole thing it lets you make modifications anywhere without risk of breaking the iptv recorder.
[13:11:54] jya_: is the stream handler re-used across all the other elements?
[13:12:18] jya_: danielk222: oh, I cloned everything, because I had no clue what I was doing and wanted a started point
[13:12:43] jya_: currently, all I would need is hlsstreamhandler and a small mod in iptvchannel to compare the type of stream.
[13:13:26] danielk222: The stream handler is used for everything in the iptv recorder. Other recorders less so and some recorders not at all.
[13:13:44] jya_: so my question was: is the stream handler re-used across all steps of the tuning/recording or is it closed / reopened.
[13:14:05] jya_: if yes, I can tweak the stream handler to simply keep the HLSringbuffer instance opened
[13:14:44] danielk222: I don't know off hand. With other recorders it wouldn't make much of a difference.
[13:15:38] jya_: as it is , the streamhandler base class, doesn't have an open or close member… so I don't believe it is re-used at all
[13:15:44] danielk222: I'd just not use it in the signalmonitor stage, just see if the url has the correct port open and leave it at that.
[13:16:15] jya_: danielk222: isn't it what the current iptvsignalmonitor is doing?
[13:17:03] danielk222: No, I believe it is checking the stream for PAT and PMT which requires some data.
[13:17:13] jya_: the other question: why when I start mythbackend does it tune to the first channel ?
[13:18:44] danielk222: It was an optimization for LiveTV made long before my time. With hardware tuners that would save a few milliseconds on LiveTV startup.
[13:19:28] jya_: i see
[13:20:20] jya_: is there anything before your time ?
[13:20:50] jya_: hum… it seems to create a new stream handler several time...
[13:21:30] danielk222: Yes, lots :)
[13:22:13] danielk222: BTW It looks like OSX uses a completely different syntax for -rpath . . . nder-mac-osx
[13:22:45] jya_:
[13:23:12] jya_: i think you can ignore gcc on mac these days
[13:23:18] jya_: it's all clang ...
[13:23:40] jya_: danielk222: is a copy of the backend log just as a tune to nasatv
[13:23:42] danielk222: Has the linker changed too?
[13:24:08] jya_: not sure
[13:24:57] jya_: i use exactly the same as your caching/get code in the hlsstreamhandler
[13:25:19] jya_: you see that each time its called with a different IPTVTuningData (I extended that one to handle HLS url)
[13:25:54] danielk222: interesting
[13:26:33] jya_: hum… i could always use a different key than devicekey
[13:26:39] jya_: and use url instead
[13:28:04] danielk222: Yeah.. though I really need to read the code myself..
[13:29:13] jya_: well, it's just the same as the iptv* code… dry little differences between the two
[13:29:21] jya_: it's 90% common
[13:29:34] jya_: except the loop in iptvstreamhandler::run()
[13:39:24] jya_: i can hack around how the run() is called and how the stream handler is called, but it wouldn't be very elegant I'm afraid… as it would heavily rely on the sequence of call and that would be ignoring all abstraction around that class
[13:40:58] jya_: damn… it does just like before…. there was no call to stop the recording after the frontend timed-out ; and so you have the HLS ring buffer downloading happily , with no one to listen for the data :(
[13:41:39] danielk222: Is it working for timed recordings then? Those are a lot less demanding than live tv
[13:41:48] jya_: haven't tried
[13:41:53] jya_: ah it just stop
[13:41:55] jya_: ped
[13:42:19] jya_: so it ran for about 3 minutes before it got finally closed
[13:45:37] danielk222: hmm, something else is off then.
[13:46:08] jya_: hum… i see.. at the closing of the signal monitor, it closes the stream data (call SetStreamData with NULL), the iptv stream handler then close itself…
[13:46:59] jya_: any particular reason you are closing the stream handler and not leave it running (talking about iptv)
[13:49:02] danielk222: Not that I can recall. It probably just made resource tracking simpler.
[13:50:01] jya_: ok…. can easily change that, it's well abstracted there and only requires a change to the signal monitor
[13:50:26] jya_: actually not even…
[13:52:23] danielk222: jya_: I've pushed a fix for the OSX rpath to the devel/mythsystem branch (based on googled info). If you can test the and from that I'd appreciate it.
[13:52:43] jya_: no worries, will test after finishing my thing here
[13:52:47] jya_: hopefully not too long
[13:53:20] danielk222: sure thing, thanks
[14:08:17] jheizer_ (jheizer_! has joined #mythtv
[14:08:58] danielk222: stuartm: github is down, so I can't look at that link. In general you should be able to use gdb as root to attach to any process and print out a stacktrace or generate a core.
[14:09:39] danielk222: And yes 700+ threads is excessive!
[14:16:39] danielk222: gigem: I've taken a cursory look at 11108. I need to sit down in a quiet room for 20 mins to really review it though. Anything that worries you?
[14:21:40] stuartm: danielk222: gdb wouldn't attach because the system wasn't allowing new threads to be created
[14:22:35] stuartm: it would just throw an error, so ironically the very problem I was trying to debug was preventing me from using the debugger
[14:23:35] danielk222: Hmm, I thought linux could handle millions of threads... ulimit?
[14:24:14] jheizer_ (jheizer_! has quit (Ping timeout: 256 seconds)
[14:24:14] ** stuartm shrugs **
[14:24:17] jya_: danielk222: I notice that there are two iptvchannel.h file. one libs/libmythtv, the other in libs/libmythtv/recorders
[14:24:20] jya_: is this on purpose?
[14:25:13] danielk222: jya_: nope, the one not in recorders is a git merge fart..
[14:25:24] jya_: good
[14:25:28] danielk222: I'll delete it.
[14:25:47] jya_: could you let me do so?
[14:26:05] jya_: don't really want to do an upgrade right away and I'm modifying the real one
[14:26:06] danielk222: yep, I'd like it even :)
[14:26:32] stuartm: I restarted the backend and I've got a bash script running to monitor the thread count, it's fairly steady when the backend is idle but rises ~12 threads whenever I watch a recording, it doesn't really drop afterwards
[14:27:58] stuartm: currently 61 threads after watching 3 recordings, from a base of 35
[14:28:12] danielk222: stuartm: There must be some long lived or blocked tasks eating up threads.
[14:28:18] ** _Dweller crosses his fingers & tests out his new buffered writer **
[14:28:19] stuartm: I'll throw gdb at it shortly
[14:30:54] stuartm: danielk222: fwiw, the commit I was referencing was this one: . . . 1885963290f5
[14:31:28] danielk222: Yeah it looks good. I was able to find it in my inbox.
[14:39:04] jya_: danielk222: with an channel (e.g. IPTVChannel), when you have a playlist, is a channel always matched to a unique URL? or is the channel used across all the URL given in the playlist?
[14:40:19] danielk222: jya_: I don't understand the question.
[14:40:39] stuartm: seems the number of threads a process can spawn on linux is complicated, and ultimately may be controlled more by the stack size allowance than a strict cap on the thread count
[14:40:51] jya_: the playlist (m3u file) is made (or could be made of) multiple URL, each to a different stream.
[14:41:30] jya_: is there one IPTVChannel instance for each of those channels, or is it re-used across the board (just changing the url for the same instance of iptvchannel)
[14:42:37] danielk222: Ah, I understand the question now. There is one reused IPTVChannel.. I believe the non-reused part is in iptvtuningdata.h
[14:43:43] jya_: i see… have to adjust my code then
[14:44:50] _Dweller: if you were really twisted, you could use your HLS client to record from my hdpvr host ;p
[14:46:43] jya_: _Dweller: it offers hls stream?
[14:47:16] _Dweller: It will.. doesn't yet.. but it's pretty close
[14:48:19] _Dweller: at the mo it's just the transport stream, sent in response to a HTTP request for the video url, with a http content-type header of video/h264
[14:49:19] _Dweller: so it's 'live' and 'http' but it's not broken into nice chunks like HLS needs yet.
[14:49:31] jya_: i see...
[14:49:52] jya_: would be a worthwhile improvement for them… could stream straight from an iphone/ipad
[14:50:11] _Dweller: I can go to anything that can run VLC already
[14:50:51] _Dweller: managed to get 5 1080i streams running out simultaneously from the hdpvr via the pi to vlc clients
[14:52:51] tonsofpcs: _Dweller: at what bitrates?
[14:52:57] _Dweller: ~8mbit
[14:53:20] _Dweller: pi cpu running about 15% doing that
[14:53:27] tonsofpcs: wow. a bit surprised that the pi's usb ethernet controller can handle 40 Mbit sustained (unless you're using HDMI ethernet?)
[14:53:39] _Dweller: standard built in ether
[14:54:14] _Dweller: I was pretty impressed.. given not only is it pushing the data out via ethernet over usb, but also reading the data in from the hd pvr over same usb controller
[14:54:34] tonsofpcs: is it one usb controller or is it two? (I never bothered to dig that far)
[14:54:40] _Dweller: just the one for the whole pi
[14:55:14] tonsofpcs: interesting. Mind you, i'm not as impressed by that (USB can handle 480 Mbps), it's more that most USB<>ethernet bridges are terrible.
[14:55:48] tonsofpcs: one of these days I want to figure out how to bridge the HDMI ethernet to normal ethernet.
[14:56:17] tonsofpcs: (Yes, the pi has HDMI ethernet. I found this out when I connected it to the parents' new 3DTV and it started saying "ethernet device detected" and went a bit crazy ;)
[14:56:47] _Dweller: I'm using pthreads to create a small socket server that accepts http requests, and has a read/spray thread that reads from the /dev/video0 and sprays out to an array of connected socket fd's.. I've just finished adding a buffered writer, with http start/stop .. which seems to be stable so far =)
[14:57:35] tonsofpcs: I lost you at 'pthreads'
[14:57:37] tonsofpcs: :)
[14:57:49] jya_: tonsofpcs: I have a USB2 gigabit ethernet adapter.. I get easily about 45MB/s
[14:58:10] stuartm: they were very careful when they picked the hardware for the Pi, so I'm not so surprised
[14:58:36] tonsofpcs: stuartm: yes, but their purpose was for little tiny dev platforms. little tiny dev platforms tend not to need to eat 100Mbps
[14:58:41] _Dweller: the pi did have a tonne of usb issues early on tho, the usb controller was more used to being a client, than a host
[14:59:10] _Dweller: but bit by it they have worked to fix it.. I'm running the prototype fiq usb branch on mine at the mo.. seems solid enough for what I'm doing
[14:59:20] stuartm: tonsofpcs: depends what's being developed I guess :)
[14:59:49] tonsofpcs: stuartm: remember, it's for classroom use ;)
[15:00:36] _Dweller: I figure I can put a pi, an hdpvr, a decent 5v psu, all together in a box, with a good ether connection to a nas, and have it use xmltv data & imdb & a db to check which films I haven't recorded yet, that are any good, and record them to the nas automatically
[15:01:42] _Dweller: (I know there are plugins for media portal to do similar.. I'd figure myth likely has something too.. but I just want this to be standalone, plug it in, tell it where the storage is, etc, then just let the movies build up)
[15:01:42] stuartm: well yes and no, the classroom use bit was always going to be subsidised initially by the sales to enthusiasts, so it had to appeal to that group as much as it did to IT teachers
[15:02:42] stuartm: _Dweller: just beware the T&Cs on imdb, we dropped them for a good reason
[15:03:23] _Dweller: I'm using and at the mo.. via a java disk based url cache, so I never request same id more than once.
[15:03:25] stuartm: and yes, MythTV can optionally record all films with a rating > x
[15:03:40] _Dweller: also finding imdb id's via google/yahoo
[15:06:44] _Dweller: kept all the epg/imdb/xmltv code in java.. I've spent far too long in java recently, and it makes handling xml etc a breeze compared to the state of my C skills ;p
[15:09:25] tonsofpcs: _Dweller: . . . aspberry-pi/ for added interface :)
[15:10:01] _Dweller: lol.. I've got plenty of 16x2's laying around I could use =) mostly the interface will be web based tho
[15:11:04] tonsofpcs: I've got two of them built up... need to figure out enough python to build a sorta-debounce chain [that should be easy, really] and a way to edit an IP address with the buttons
[15:11:37] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[15:13:28] _Dweller: button 1, select default network template.. (192.168.0.X, 192.168.X.X, 10.X.X.X, X.X.X.X).. button 2 confirm, button 1, step through values for left most X, button 2 confirm, repeat with next X, until complete
[15:14:52] _Dweller: or speculatively attempt a dhcp assignment, then release the address, and offer editing of the assigned address.. (possibly follow up with an attempt to request the edited address as a dhcp address to error if the edited one is in dhcp range..)
[15:14:59] jya_: now that' weird… my frontend keeps telling me that my backend isn't there :(
[15:17:46] tonsofpcs: _Dweller: it's more the field editing that needs to be done. There's 5 buttons, so moving around and 'cancel' are easily done. It's more a 'read an ip address, track where cursor is, [show cursor], track what value is in each position, output IP address' that is the issue
[15:17:59] tonsofpcs: (oh, and a full can fit on the screen)
[15:18:29] _Dweller: with the approach I suggest, you'll only need 2 buttons.. just rewrite the display every time button 1 is pressed
[15:19:33] tonsofpcs: _Dweller: ok, how do I enter
[15:19:56] _Dweller: cycle until X.X.X.X .. set 17, set 246, set 23, set 93
[15:20:01] tonsofpcs: I have to press buttons 17+246+23+93 times?
[15:20:01] _Dweller: ur thumb will fall off ;p
[15:20:13] tonsofpcs: (+4+4)
[15:20:27] _Dweller: do you need to enter totally random addresses, or just ones from the users local network tho ?
[15:20:28] tonsofpcs: and again, that leaves the same issues.
[15:20:38] tonsofpcs: _Dweller: it could have a public static.
[15:20:57] ** _Dweller would just optimise for the 192.168.0.X case ;p **
[15:20:59] tonsofpcs: and it will need a netmask and gateway entered as well.
[15:21:19] tonsofpcs: _Dweller: even in my personal use, that's completely useless.
[15:21:26] stuartm: jya_: strangely enough, mines just started doing the same thing
[15:21:31] jya_: ohhh the nice deadlock
[15:21:44] jya_: stuartm: here it's entirely my fault :)
[15:22:04] tonsofpcs: mine does that on boot... need to manually kill and relaunch backend... haven't bothered to troubleshoot.
[15:22:23] stuartm: jya_: actually, now that I think about it, it's my fault here too
[15:22:52] jya_: i create a qmutextlocker, and call Close() which does the same
[15:23:05] stuartm: I forgot that I'd left gdb attached to the backend
[15:23:34] stuartm: it was running, but in a frozen state
[15:23:42] jya_: actually danielk222 : there's a potential one in in IPTVChannel
[15:28:21] wagnerrp: _Dweller: so you're using an RPi to make the HDPVR network-attached?
[15:29:20] _Dweller: wagnerrp: in a nutshell =) .. If I knew the specs for hdhomerun protocol, I'd be tempted to make it emulate it ;p
[15:30:41] wagnerrp: the communications libraries are open source, but i'm not sure how well they document the protocol itself
[15:30:56] _Dweller: not too well .. I had a google around..
[15:31:08] _Dweller: I'd likely have to buy one and sniff it
[15:31:24] wagnerrp: i mean you could just grab their libraries and read through the code
[15:31:26] wagnerrp: no need to sniff it
[15:31:51] wagnerrp: although you would be ripping out all their control codes, and adding new ones for bitrate and other capture parameters
[15:31:59] wagnerrp: so all you would really be left with is a basic UDP stream
[15:32:04] _Dweller: aye..
[15:32:41] ** _Dweller is slowly getting sick of Rock of Ages.. been using it as a test video source all weekend.. now on playthrough 12.. it goes on, and on, and on, and on.. **
[15:33:26] _Dweller: also.. chrome actually sends GET requests for predictive urls in the address bar.. this is bad if you have urls for start/stop recording, and want the 'status' url ;p
[15:37:22] gigem: danielk222: No, no real concerns. Since it reworks the timing that you last reworked, I thought you should look at it.
[15:50:29] _Dweller: cool... buffered writer works =) writing to cifs mountpoint while streaming to 2 vlc clients, one wired, one wireless
[15:50:50] sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Remote host closed the connection)
[15:51:07] sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv
[15:51:18] _Dweller: before streaming to a 2nd vlc while recording without buffered writer would cause the hdpvr to lose signal ( I guess because I wasn't pulling data off it's device fast enough )
[15:52:50] _Dweller: max buffer load is floating around 600 * 4k buffers.. with average pending write queue floating around 200 * 4k
[15:54:34] _Dweller: re HLS and RPi, there's been some good work recently at streaming the pi camera via HLS.. it needs a little stream filter to reinsert the SPS/PPS packets (it only sends them at stream start, and they need to be there each chunk)
[16:06:47] jya_: danielk222: sure you pushed your commit about path?
[16:06:51] jya_: rpath
[16:08:50] rsiebert (rsiebert! has joined #mythtv
[16:11:48] rsiebert_ (rsiebert_! has quit (Ping timeout: 245 seconds)
[16:13:35] paul-h: jya_: this what you are looking for
[16:14:00] jya_: ah,, so igithub isn't updated?
[16:15:09] jya_: danielk222: that fix isn't correct… i had tried it myself a little while before (replacing = with ,)… it couldn't find libmythbase (no make install had been completed to this point0
[16:22:27] _Dweller: my current hdpvr streaming / recording server if anyone has a use for it =)
[16:39:31] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 264 seconds)
[16:44:18] stuartm: danielk222: gdb isn't revealing much about these threads, they aren't pool threads (MPoolThread) that I can tell but they are MThreads, a full bt doesn't reveal where they are being created or any local variables, many have event loops, some don't
[16:44:46] stuartm: I think I'll just have to stick in some debug logging at thread creation
[16:45:52] stuartm:
[16:47:04] stuartm: there's a reasonably consistent number generated on the backend when playback is started on the frontend (12), when exiting playback 2 threads are destroyed and the rest are left running
[16:50:58] danielk222: stuartm: Every MThread should have a name that tells you who created it..
[16:53:17] stuartm: well gdb isn't showing it, I'll just add a LOG/cerr there, that will give me better correlation with events occuring on the frontend anyway
[16:54:36] stuartm: paul-h: results for coverity now include zoneminder (and mythweather) –
[17:11:24] stoffel (stoffel! has joined #mythtv
[17:12:47] danielk222: jya_: I also added ../../ as an rpath for the libmythbase
[17:22:55] _Dweller: ouch.. might need to add more buffers ;p gave myself 4096 * 4k, during this record, it maxed at 3061 buffers used.. mebbe 8192 (32mb) worth will be better.. does myth have a write buffer for storing to disk, if so .. how big ? (for cifs ;p )
[17:26:59] Steve-Goodey (Steve-Goodey! has joined #mythtv
[17:31:52] danielk222: _Dweller: Yes, it grows as needed, capped at 128MB. Before we had a buffer that shrinks and grows as needed we had a fixed 9.8MB buffer.
[17:33:57] _Dweller: danielk22: thanks, mine grows as needed, I don't have anything shrinking it.. tho my RPi only has 256mb total.. and some of that is given to the GPU..
[17:34:54] _Dweller: mine currently capped at 16mb tho.. so def a bit small.. will raise it & consider adding something to free up buffers if too many end up free..
[17:38:55] _Dweller: I sense yet another pthread coming into existence ;p loop while sleeping for a sec, then tracking the # of free buffers, and if it's been above 1024 for the last 5 times, then free up 1024 buffers
[17:43:53] sl1ce (sl1ce! has joined #mythtv
[17:46:57] sl1ce (sl1ce! has quit (Remote host closed the connection)
[17:48:53] ovrflw0x (ovrflw0x!~ovrflw0x@unaffiliated/ovrflw0x) has joined #mythtv
[17:48:55] ovrflw0x: when i connect laptop to tv is there any easy to use interface to access youtube, surf web easily? as default Windows 7 interface is too small and i have to use "magnify" app to see...
[17:58:49] stoffel (stoffel! has quit (Remote host closed the connection)
[18:45:43] jarle (jarle! has joined #mythtv
[18:57:36] stuartm: danielk222: could be that I'm not interpreting this thread logging properly, it looks as though we're leaking threads in the socket code – – If you follow closely the threads created for socket 102, they take ownership of the RingBuffer threads and destroy those but aren't destroyed themselves
[18:59:42] dekarl (dekarl! has quit (Read error: Operation timed out)
[19:00:22] dekarl (dekarl! has joined #mythtv
[19:02:53] ovrflw0x (ovrflw0x!~ovrflw0x@unaffiliated/ovrflw0x) has quit (Quit: Leaving)
[19:22:52] danielk222: stuartm: Isn't line 41 where the MThread is deleted? It prints "~MThread".
[19:24:25] stuartm: that's where it's destroying the RingBuffer thread _in_ the file transfer thread
[19:26:27] stuartm: I've compiling now with some additional debugging around the FT stuff
[19:26:43] sl1ce (sl1ce! has joined #mythtv
[19:28:40] sl1ce (sl1ce! has quit (Remote host closed the connection)
[19:57:43] stuartm: danielk222: here's the same sequence, cut down to just the relevant period and with -v socket enabled  –
[20:00:09] stuartm: at the top we create a new MythSocket, for socket #135, henceforth this instance is known as 127c0c0, it creates a Ringbuffer thread (via creation of an FT instance), the connection is then closed, the FT instance and ringbuffer thread are destroyed, but the dtor for 127c0c0 is not seen
[20:00:09] ** MythLogBot **
[20:02:28] stuartm: finally we create yet another MSocket for socket 135. This can be repeated 2–3 times in close succession with the dtor for the FT socket created never being called ... but I'm just not sure how it happens yet
[20:03:00] jpharvey (jpharvey! has joined #mythtv
[20:11:11] stuartm: ah, ok I think I see the problem, it's a Reference Counter mis-match for FT sockets
[20:17:20] stuartm: only question now is whether FileTransfer should take ownership of the socket and be responsible for deleting it, or whether that's up to the user of FT, i.e. MainServer
[20:17:48] jpharvey (jpharvey! has quit (Remote host closed the connection)
[20:26:06] jpharvey (jpharvey! has joined #mythtv
[20:26:28] stuartm: danielk222: fix seems to reduce the 'leak' significantly and maybe completely, I just need to monitor the thread count over a longer period of time
[20:36:22] stichnot (stichnot! has joined #mythtv
[20:36:23] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[20:36:23] stichnot (stichnot! has quit (Changing host)
[20:52:27] len (len! has joined #mythtv
[21:20:32] Steve-Goodey (Steve-Goodey! has quit (Quit: Konversation terminated!)
[21:23:06] SteveGoodey (SteveGoodey! has quit (Quit: Konversation terminated!)
[21:30:30] _Dweller (_Dweller! has quit (Quit: Leaving)
[21:32:03] IReboot (IReboot! has quit (Quit: Ex-Chat)
[21:41:18] sl1ce (sl1ce! has joined #mythtv
[21:42:29] twm (twm!~tommost__@rhlug/tomwm) has joined #mythtv
[21:42:41] twm (twm!~tommost__@rhlug/tomwm) has left #mythtv ()
[22:10:44] kenni (kenni!~kenni@mythtv/developer/kenni) has quit (Ping timeout: 240 seconds)
[22:14:01] paul-h (paul-h!~Paul@ has quit (Quit: Konversation terminated!)
[22:22:02] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!)
[22:23:03] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv
[22:23:03] kenni (kenni! has joined #mythtv
[22:23:03] kenni (kenni!~kenni@mythtv/developer/kenni) has joined #mythtv
[22:23:03] kenni (kenni! has quit (Changing host)
[22:41:55] natanojl (natanojl! has quit (Ping timeout: 246 seconds)
[23:12:32] aarcane (aarcane! has quit (Quit: Leaving)
[23:19:49] jya_: danielk222: you're here?
[23:27:06] jya_: I've been thinking about the channel classes. And how I could make it that the stream handler isn't deleted between the time the signal monitor complete and recording start
[23:27:59] jya_: it probably doesn't matter for stream that can start very quickly, but for HLS where it can take several seconds (30s sometimes): it's a pain...
[23:29:59] peper03 (peper03! has quit (Quit: Konversation terminated!)
[23:30:08] jya_: The problem is that Channel::SetStreamData is used for both setting the stream data, and telling the channel that we're done (SetStreamData(NULL). The signal monitor set it to NULL in its destructor. So if I don't close the stream handler when given a 0, I get much quicker start, but then the stream handler is never closed when I quit live tv
[23:30:23] jya_: Two way I could think of fixing it
[23:31:55] jya_: 1- I had a new method to Channel ; Channel::Pause that will indicate that the channel isn't going to be used in the near future and in that state, Channel::SetStreamData(NULL) can delete the stream handler. If not it keeps it alive (only removed the stream data from the listener)
[23:32:57] jya_: 2- When SetStreamData is called with NULL; we don't actually close the stream handler but we marked it for deletion. If xx seconds later nothing has happened; we delete it
[23:33:01] jheizer_ (jheizer_! has joined #mythtv
[23:33:59] jya_: To me, method 1 is more elegant. But is a bit more invasive. Plus I would need to know where to mark the channel as paused and that requires more knowledge of the recorder class than I currently have
[23:34:55] jya_: method 2 is a bit easier to implement, but that will need to add use of a timer...
[23:34:58] jya_: what do you think?
[23:39:17] jheizer_ (jheizer_! has quit (Ping timeout: 248 seconds)

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