| Thursday, January 27th, 2011, 00:00 UTC | ||
| [00:00:52] | stuartm: | Beirdo: that's interesting, I just pushed 3 commits, but only one commit hook was triggered |
| [00:01:50] | Beirdo: | it usually does one hook per push |
| [00:02:02] | Beirdo: | with all of what's pushed in that hook's data |
| [00:02:48] | stuartm: | email/irc bot only mention the merge commit :( |
| [00:03:08] | stuartm: | guess I'll need to email the -dev list with the distclean warning |
| [00:09:04] | sphery: | stuartm: heh, yeah, I was wondering why my push message came through before yours |
| [00:11:32] | stuartm: | goes without saying that the changes weren't tested on OSX/Windows ... |
| [00:17:07] | Beirdo: | yeah |
| [00:17:13] | Beirdo: | frigging stupid hook |
| [00:17:27] | Beirdo: | another thing to add to my list... see if there's a better way to do that hook |
| [00:17:44] | Beirdo: | it's done this to us a couple times now inexplicably |
| [00:18:05] | Beirdo: | and if it's pissing *me* off, I'm sure some others are getting annoyed too :) |
| [00:21:32] | kc (kc!~Casper@unaffiliated/kc) has joined #mythtv | |
| [00:22:07] | stuartm: | Beirdo: seems to be on their end since the same happened with the IRC bot |
| [00:22:31] | Beirdo: | yeah, it does. :( |
| [00:22:53] | Beirdo: | which limits how we can fix it... pretty significantly. |
| [00:23:15] | Beirdo: | but with the plans to put SVN back in place, we can do the emails differently as part of that |
| [00:23:39] | stuartm: | only thing we can do for now is to file a ticket with github |
| [00:25:39] | Beirdo: | yeah, true |
| [00:31:29] | kth (kth!~kth@dyndsl-080-228-191-153.ewe-ip-backbone.de) has quit (Quit: Leaving.) | |
| [00:54:36] | Mousey (Mousey!~wtfisme@ross154.net) has quit (Remote host closed the connection) | |
| [00:55:19] | sphery: | stuartm: If we add UNDO/REDO key bindings for http://code.mythtv.org/trac/ticket/8901 , would it be better to put them in Global context (to allow use in text areas, etc., if we ever decide to program that) or in TV Editing? Also, what are your thoughts on assigning defaults? (He used the Windows defaults of Ctrl-Z/Ctrl-Y--where Ctrl-Y happens to conflict with PREVSOURCE default.) |
| [00:59:31] | holomntn1 (holomntn1!~Joe@71-93-231-1.dhcp.mdfd.or.charter.com) has quit (Read error: Connection reset by peer) | |
| [01:01:06] | holomntn (holomntn!~Joe@71-93-231-1.dhcp.mdfd.or.charter.com) has joined #mythtv | |
| [01:12:47] | kormoc is now known as kormoc_afk | |
| [01:27:04] | markk_: | can anyone point me to a function that converts a storage group url to it's 'local' version? – i.e. if the sg file is actually local, what's it's real path |
| [01:29:04] | iamlindoro: | StorageGroup::FindRecordingFile(QString filename) |
| [01:29:50] | iamlindoro: | Not url, precisely, but same effect |
| [01:33:15] | markk_: | thanks (I think!) |
| [01:34:13] | iamlindoro: | np, hope it at least puts you on the right track-- if not, Captain_Murdoch will surely know deeper information |
| [01:36:22] | markk_: | I just can't see how to use it :) I think we need to pass the real path to libbluray if the bluray |
| [01:36:26] | markk_: | is local |
| [01:39:41] | iamlindoro: | I'm not sure I follow |
| [01:40:13] | iamlindoro: | My local and remote Blu-ray content works in Myth in the status quo-- what's currently not working properly? |
| [01:44:15] | markk_: | iamlindoro: 2 related issues – on at least one disc here, there is a significant difference when playing back with mythavtest pointed directly at the local file and using the storage group url. appears to be firstly because mythiowrapper assumes a remote file and secondly, the remotfile 'stat' and 'read' is going wrong somewhere. |
| [01:44:45] | iamlindoro: | Ah, certainly best to talk to Captain_Murdoch then, as he's both the authority on storage groups and the wrapper author :) |
| [01:45:08] | markk_: | it tries to read the same clpi file a couple of dozen times or more – and sometimes just time out. with local file access, it gets it first time |
| [01:59:05] | kormoc_afk is now known as kormoc | |
| [02:32:03] | sphery: | So, does anyone have any idea how this "don't update all the info in programinfo, unless we need to" is supposed to work? It completely breaks the Previously Recorded page's ability to determine whether to show the "Allow this episode to re-record" (forget history) or not, since programflags is 0, because we've "optimized" out the query when we created all the programinfos |
| [02:34:19] | sphery: | Was looking at how danielk fixed it for not running commflagging on commercial free channels ( http://svn.mythtv.org/trac/ticket/8491 and https://github.com/MythTV/mythtv/commit/b1a9c1f9 ), but it seems he just updates the FL_CHANCOMMFREE flag... So, do I do the same for FL_DUPLICATE ? And if so, why are we even optimizing out the reading of that info, anyway? |
| [03:00:23] | sphery: | ok, looks like it is trying to load it but we're losing it somewhere... will dig deeper |
| [03:15:42] | Dave123 (Dave123!~dave@cpe-74-74-222-96.rochester.res.rr.com) has quit (Read error: Connection reset by peer) | |
| [03:45:02] | markk_: | can someone (sphery??) remind me on the current approach to 'always stream files' i.e. do we always stream files now by default? or do we attempt to open them directly if local? |
| [03:48:00] | sphery: | markk_: Heh, well, we still obey the setting, AlwaysStreamFiles , but have no UI widget for flipping it. So if it's set in your DB, you're streaming. The only real change--other than removing the GUI widget for it--was that if it's set, we now stream /even/ if the recording was recorded by this host (previously, we ignored the setting if the recording was made by the current host). |
| [03:49:06] | sphery: | In most databases, AlwaysStreamFiles should be undefined or not set, so we'll get the default behavior, which is 0/false, meaning that if the file is available on the file system, we'll read from that, and we only stream if we can't find the file "locally" |
| [03:51:43] | markk_: | sphery: thanks – no mention of alwaysstreamfiles in my db – which seems odd (it's old enough) |
| [03:52:12] | sphery: | the plan for the future is to remember/make available the information that MainServer::GetFilesystemInfos() gets (i.e. which file systems are available and which are local and such) and then determine what is the most efficient means of getting the file from the disk to the frontend |
| [03:53:30] | markk_: | sphery: can you point me to the correct spot in the code where the stream decision is made? |
| [03:54:06] | sphery: | heh, not in my DB, either... Don't know why |
| [03:54:18] | sphery: | it's in libs/libmyth/programinfo.cpp +2003 |
| [03:54:39] | sphery: | where that's used for ProgramInfo::GetPlaybackURL() |
| [03:55:06] | sphery: | oh, wait, it is there--typo'ed my query :) |
| [03:55:11] | markk_: | ah ok – I was looking in the right place:) |
| [03:56:55] | markk_: | hrm – but me only use GetplaybackURL if it's a recording... (tv_play.cpp 2044) |
| [03:57:44] | markk_: | elmojo: just spotted where we're not using the longer livetv timeout on ringbuffer creation |
| [03:57:53] | sphery: | yeah, I don't know how the video stuff works... :( Might be some opportunities for consolidation, there--there will certainly be some when we go to http://code.mythtv.org/trac/wiki/TaskRecordedFile + http://code.mythtv.org/trac/attachment/wiki/T . . . e_schema.png |
| [04:02:26] | markk_: | crap – GetPlaybackURL gives us the local path but we no longer recognise it as a bd... |
| [04:28:39] | darkdrgn2k: | iamlindoro: krap i knew you would do that....... why did i even start :( |
| [04:33:32] | iamlindoro is now known as BanHammerBrown | |
| [04:33:44] | BanHammerBrown is now known as iamlindoro | |
| [05:05:27] | purserj (purserj!~purserj@hosting.collaborynth.com.au) has quit (Ping timeout: 265 seconds) | |
| [05:06:06] | purserj (purserj!~purserj@hosting.collaborynth.com.au) has joined #mythtv | |
| [05:18:30] | Captain_Murdoch: | markk_, I think it might be best to have a short bit of code in mythiowrapper.cpp in mythfile_open() to detect if the file is local instead of basing that decision solely on whether the path starts with myth:// by the time we get to mythfile_open, we already know if it's a DVD or BD, so we don't have to worry about preserving the dvd: or bd: at the beginning of any filenames. give this patch a try and see if it helps: http |
| [05:18:31] | Captain_Murdoch: | ://pastebin.com/Lk3qDTdA |
| [05:19:50] | kenni (kenni!~kenni@mythtv/developer/kenni) has quit (Read error: Operation timed out) | |
| [05:24:25] | markk_: | Captain_Murdoch: thanks – I'd thought about that approach, but having looked at the code I was wondering whether some of the higher level code should be fixed/improved :) i.e. we should just be passing the bluray object the correct path in the first place |
| [05:25:00] | markk_: | and of course, still doesn't begin to address the issue of what's going wrong when it's a remote path |
| [05:26:25] | markk_: | Captain_Murdoch: are there any optimisations that may be involved if for small files? the file that is causing problems is only 1500 bytes |
| [05:26:44] | Captain_Murdoch: | we could put the logic higher up the chain as well or instead. |
| [05:26:52] | J-e-f-f-A (J-e-f-f-A!~J-e-f-f-A@unaffiliated/j-e-f-f-a) has quit (Quit: Oh No!!!! ;-)) | |
| [05:28:09] | markk_: | my gut feeling is that ProgramInfo::GetPlaybackURL needs to be generalised – currently it is geared towards recordings |
| [05:28:10] | Captain_Murdoch: | one optimization that (I think) daniel thought up was to return the first X bytes of the file when we open a remote ringbuffer. that would cut down on one FE->BE request for small files since the data would already be in the buffer. we talked about that when he was working on the ringbuffer a while back. |
| [05:28:26] | Beirdo^2 (Beirdo^2!~gjhurlbu@32.174.162.104) has joined #mythtv | |
| [05:28:37] | Beirdo^2 (Beirdo^2!~gjhurlbu@mythtv/developer/beirdo) has joined #mythtv | |
| [05:28:37] | Beirdo^2 (Beirdo^2!~gjhurlbu@32.174.162.104) has quit (Changing host) | |
| [05:28:55] | Captain_Murdoch: | yeah, logic could move out of there into a general helper or into a routine in storagegroup.cpp |
| [05:29:30] | Captain_Murdoch: | will also apply when we get mythmusic and mythgallery converted over to using remote SG's. |
| [05:30:22] | J-e-f-f-A (J-e-f-f-A!~J-e-f-f-A@unaffiliated/j-e-f-f-a) has joined #mythtv | |
| [05:32:12] | markk_: | anyway – it's curry o'clock :) |
| [05:32:17] | markk_: | biab |
| [05:32:25] | Captain_Murdoch: | in the BD code, I believe that 1500 bytes causes at least 4 FE->BE commands open/stat/read/close. the BD lib was doing a seek in there, but I converted that to a mythfile_stat call so we didn't have to seek to the end. |
| [05:32:50] | Captain_Murdoch: | almost bed o'clock for me, be around maybe another half hour or so. |
| [05:39:36] | Captain_Murdoch: | markk_, could put that code inside RingBuffer::Create() I guess. at the very top, so we cut out the RemoteFile::Exists() and other FE->BE calls if the FE is on the BE. |
| [05:48:52] | kenni (kenni!~kenni@pfsense.dhcp.pop.k-net.dk) has joined #mythtv | |
| [05:48:53] | kenni (kenni!~kenni@pfsense.dhcp.pop.k-net.dk) has quit (Changing host) | |
| [05:48:53] | kenni (kenni!~kenni@mythtv/developer/kenni) has joined #mythtv | |
| [06:01:24] | jpabq- (jpabq-!~jpabq@174-28-178-122.albq.qwest.net) has quit (Ping timeout: 240 seconds) | |
| [06:01:27] | jpabq (jpabq!~jpabq@mythtv/developer/jpabq) has quit (Ping timeout: 240 seconds) | |
| [06:02:20] | jpabq (jpabq!~jpabq@mythtv/developer/jpabq) has joined #mythtv | |
| [06:03:19] | jpabq- (jpabq-!~jpabq@71-37-158-160.albq.qwest.net) has joined #mythtv | |
| [06:10:58] | J-e-f-f-A (J-e-f-f-A!~J-e-f-f-A@unaffiliated/j-e-f-f-a) has quit (Quit: Oh No!!!! ;-)) | |
| [06:13:25] | J-e-f-f-A (J-e-f-f-A!~J-e-f-f-A@unaffiliated/j-e-f-f-a) has joined #mythtv | |
| [06:18:41] | skd5aner (skd5aner!~skd5aner@cpe-069-132-082-180.carolina.res.rr.com) has quit (Ping timeout: 264 seconds) | |
| [06:20:20] | skd5aner (skd5aner!~skd5aner@cpe-069-132-082-180.carolina.res.rr.com) has joined #mythtv | |
| [06:37:32] | simonckenyon (simonckenyon!~simoncken@195.7.61.12) has joined #mythtv | |
| [06:55:05] | Goga777 (Goga777!~Goga777@shpd-92-101-137-50.vologda.ru) has joined #mythtv | |
| [07:24:48] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [07:28:20] | Goga777 (Goga777!~Goga777@shpd-92-101-137-50.vologda.ru) has quit (Remote host closed the connection) | |
| [07:30:27] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 265 seconds) | |
| [07:45:55] | sphery (sphery!~mdean@mythtv/developer/sphery) has quit (Ping timeout: 265 seconds) | |
| [07:51:28] | sphery (sphery!~mdean@user-0c6s50s.cable.mindspring.com) has joined #mythtv | |
| [07:51:28] | sphery (sphery!~mdean@user-0c6s50s.cable.mindspring.com) has quit (Changing host) | |
| [07:51:28] | sphery (sphery!~mdean@mythtv/developer/sphery) has joined #mythtv | |
| [08:00:07] | wagnerrp: | Captain_Murdoch: what does the 'checkfiles' stuff in ANN Filetransfer do? |
| [08:00:43] | wagnerrp: | it looks like its checking for the existence of additional files located in the same directory as the main file, but for what use? |
| [08:00:50] | wagnerrp: | screenshots or something? |
| [08:21:01] | simonckenyon|2 (simonckenyon|2!~simoncken@195.7.61.12) has joined #mythtv | |
| [08:22:45] | simonckenyon (simonckenyon!~simoncken@195.7.61.12) has quit (Ping timeout: 260 seconds) | |
| [08:25:08] | andreax (andreax!~Andreaz@tmo-109-241.customers.d1-online.com) has joined #mythtv | |
| [08:29:27] | deaman (deaman!~deaman@nat/trolltech/x-lqducqqdqlmdxbli) has joined #mythtv | |
| [09:23:07] | jamesba (jamesba!~jamesba@132.185.140.26) has joined #mythtv | |
| [09:37:31] | simonckenyon|2 (simonckenyon|2!~simoncken@195.7.61.12) has quit (Remote host closed the connection) | |
| [09:57:17] | simonckenyon (simonckenyon!~simoncken@195.7.61.12) has joined #mythtv | |
| [10:33:38] | kth (kth!~kth@dyndsl-080-228-190-011.ewe-ip-backbone.de) has joined #mythtv | |
| [10:49:38] | Goga777 (Goga777!~Goga777@shpd-92-101-137-50.vologda.ru) has joined #mythtv | |
| [11:05:02] | mike|3 (mike|3!~mike@c-24-21-63-118.hsd1.or.comcast.net) has quit (Remote host closed the connection) | |
| [11:05:56] | mike|2 (mike|2!~mike@c-24-21-63-118.hsd1.or.comcast.net) has joined #mythtv | |
| [11:25:54] | Goga777 (Goga777!~Goga777@shpd-92-101-137-50.vologda.ru) has quit (Remote host closed the connection) | |
| [11:41:50] | holomntn (holomntn!~Joe@71-93-231-1.dhcp.mdfd.or.charter.com) has quit (Ping timeout: 240 seconds) | |
| [11:44:05] | Goga777 (Goga777!~Goga777@shpd-92-101-137-50.vologda.ru) has joined #mythtv | |
| [11:51:26] | stuarta: | 9512 looks like a straight forward set of patches |
| [11:54:32] | holomntn (holomntn!~Joe@71-93-231-1.dhcp.mdfd.or.charter.com) has joined #mythtv | |
| [12:36:26] | Goga777 (Goga777!~Goga777@shpd-92-101-137-50.vologda.ru) has quit (Remote host closed the connection) | |
| [12:44:32] | danielk22 (danielk22!~danielk@121.246.154.93) has joined #mythtv | |
| [12:49:54] | stuartm: | Captain_Murdoch: can you remember why mythuifilebrowser.cpp/h was moved into libmyth? |
| [12:57:04] | danielk22 (danielk22!~danielk@121.246.154.93) has quit (Quit: Leaving.) | |
| [13:36:29] | simonckenyon (simonckenyon!~simoncken@195.7.61.12) has quit (Ping timeout: 276 seconds) | |
| [14:05:44] | jcarlos (jcarlos!~quassel@85.137.96.30.dyn.user.ono.com) has quit (Read error: Connection reset by peer) | |
| [14:06:54] | jcarlos (jcarlos!~quassel@85.137.96.30.dyn.user.ono.com) has joined #mythtv | |
| [14:13:53] | Captain_Murdoch: | stuartm, it needed MythContext to communicate with the BE. I wanted to move that into libmythui at some point now that we have MythCoreContext |
| [14:14:34] | Captain_Murdoch: | wagnerrp, checkfiles is something that I think daniel added to speed up the subtitle loading. 'git blame' to verify. :) |
| [14:15:26] | wagnerrp: | ok thanks |
| [14:15:39] | stuartm: | Captain_Murdoch: ok ... I'll move it back again, I'm currently auditing libmyth and shifting stuff out of that lib |
| [14:15:50] | Captain_Murdoch: | stuartm, great, thanks. |
| [14:15:51] | wagnerrp: | i sort of understood what it did... just didnt understand why it did |
| [14:16:01] | wagnerrp: | i never even knew that existed, much less that anything used it |
| [14:16:19] | Captain_Murdoch: | wagnerrp, I think it was part of the playback startup optimizations done a while ago. |
| [14:33:35] | markk_: | Captain_Murdoch: ignoring the local vs remote stuff for now, I worked out the 'issue' with some bluray discs. For example, on one of my discs, the main title has 100 clips – and when it is building the title information, libluray opens the same small clpi (clip info) file 100 times. |
| [14:34:37] | markk_: | it may only take about 0.02 seconds for each remote file open/read/close cycle – but it soon adds up to a significant delay. |
| [14:35:49] | markk_: | - hrm, that should read 0.05 seconds, and it reads each clpi file twice... |
| [14:38:06] | Captain_Murdoch: | markk_, that sounds like what we saw during our initial testing where one BD with 100+ files took over a minute to startup. we also noticed that it opened each file twice. |
| [14:38:38] | Captain_Murdoch: | I think it might have been stuartm who had a sample like that, but I might be mistaken |
| [14:40:32] | Captain_Murdoch: | I believe stuartm was looking into moving the 'decoding' into the backend instead of just serving up block data from the BE, it would be the one using libmythdvdnav, libmythbluray, etc.. and the proto would be extended to support playback using those remote libs. |
| [14:44:02] | stuartm: | I was looking into that for dvd playback, at least initially, and I had a partially working solution, but I got to the point where I realised I'd need to modify the protocol and so it ended up getting put on hold |
| [14:45:03] | stuartm: | not that modifying the protocol was an issue, merely that the size of the job was increasing and there were other things I wanted to get done |
| [14:45:53] | markk_: | Captain_Murdoch: assuming libbluray really needs to do that and is working correctly (i.e. they don't know in advance that the clipinfo for 100 clips is in the same file), I'm wondering whether some simple caching of file handles in mythiowrapper would work – i.e. don't close a file handled until it hasn't actually been used for X time or we have more than Y files open. |
| [14:47:59] | j-rod|afk is now known as j-rod | |
| [14:48:19] | stuartm: | markk_: that will help for the delay issue, especially with blu-ray |
| [14:49:26] | gigem_ (gigem_!~david@host137.12.intrusion.com) has joined #mythtv | |
| [14:49:35] | stuartm: | the remote decode solution was for encrypted DVD playback primarily – decss requires local access to the file |
| [14:56:24] | bbc581 (bbc581!~bbc581@74-129-133-90.dhcp.insightbb.com) has joined #mythtv | |
| [14:58:07] | Captain_Murdoch: | markk_, that would help. another optimization we made in mythiowrapper was to use RemoteFile directly on the FE instead of a full RingBuffer if the file was less than 50KBytes. that was for speedup for all those small files which were being read (twice). Each RemoteFile does use up a backend connection though, so keeping them open would mean we'd have lots of BE connections open at the same time. One other solution I considere |
| [14:58:07] | Captain_Murdoch: | d was putting in a global data cache for either mythiowrapper or RingBuffer data. instead of just caching a file handle, cache the < 1KB of data as well for those tiny files, so we don't need to send a seek or read to the BE the next time around. we could do this in conjunction with caching file handles, and flush the cache when we close the handle. that would duplicate some RB functionality, but this would be only for small fi |
| [14:58:08] | Captain_Murdoch: | les. |
| [15:13:06] | stuartm: | gigem: git mv |
| [15:13:31] | stuartm: | gigem: https://github.com/MythTV/mythtv/commit/f32d7 . . . 2234862d4a87 |
| [15:15:36] | stuartm: | heh, git's merging sucks |
| [15:16:21] | stuartm: | branched master an hour ago, made changes, merged back to master and there are conflicts |
| [15:16:36] | stuartm: | how can that be when master hasn't changed in that time? |
| [15:16:55] | stuartm: | and the conflicts are dumb, even patch wouldn't struggle with them |
| [15:17:50] | Jordack (Jordack!~jordack@h69-131-44-221.mdsnwi.tisp.static.tds.net) has joined #mythtv | |
| [15:19:43] | stuartm: | this is the most complicated of the conflicts – http://mythtv.pastebin.com/JxndPtx6 |
| [15:20:00] | stuartm: | note that the line numbers have no changed, as the files haven't changed |
| [15:20:27] | gigem_: | stuartm: ok, just checking to be sure. |
| [15:20:45] | andreax (andreax!~Andreaz@tmo-109-241.customers.d1-online.com) has quit (Read error: Connection reset by peer) | |
| [15:23:28] | kth (kth!~kth@dyndsl-080-228-190-011.ewe-ip-backbone.de) has quit (Ping timeout: 250 seconds) | |
| [15:23:43] | kth (kth!~kth@dyndsl-080-228-178-139.ewe-ip-backbone.de) has joined #mythtv | |
| [15:24:45] | stuartm: | libmyth is on a rapid weight loss diet |
| [15:26:07] | laga: | i hope the skin doesn't get flabby |
| [15:28:50] | stuartm: | where libmyth is going, I don't think flabby skin will matter |
| [15:32:40] | deaman (deaman!~deaman@nat/trolltech/x-lqducqqdqlmdxbli) has quit (Remote host closed the connection) | |
| [15:35:26] | stuarta: | stuartm: patch wouldn't have coped with that conflict |
| [15:38:17] | stuartm: | there wasn't a conflict to start with |
| [15:39:03] | kth1 (kth1!~kth@dyndsl-080-228-178-139.ewe-ip-backbone.de) has joined #mythtv | |
| [15:39:03] | kth (kth!~kth@dyndsl-080-228-178-139.ewe-ip-backbone.de) has quit (Read error: Connection reset by peer) | |
| [15:39:18] | kth1 (kth1!~kth@dyndsl-080-228-178-139.ewe-ip-backbone.de) has quit (Remote host closed the connection) | |
| [15:39:49] | stuarta: | i saw several in what you put in the pastebin |
| [15:44:21] | stuartm: | ? |
| [15:47:51] | stuartm: | goto – "<stuartm> branched master an hour ago, made changes, merged back to master and there are conflicts" |
| [15:48:22] | stuarta: | http://mythtv.pastebin.com/JxndPtx6 |
| [15:48:29] | stuartm: | and since there cannot have been any conflicts, patch would not have had the same problem |
| [15:49:50] | stuarta: | heh oops. rereading it's shouldn't have been a conflict. however the context is missing so it's hard to tell |
| [15:50:06] | stuartm: | stuarta: which just demonstrates that it should not have conflicted – the merge added two filenames to one line and a new line after that, the source lines did not change, ergo patch would have had context to adjust |
| [15:50:47] | stuartm: | it's frankly bizarre, but par for the course with git unfortunately |
| [15:52:43] | stuarta: | yeah that is a bit odd |
| [15:53:14] | stuartm: | I'm just exasperated :) |
| [15:53:46] | stuarta: | i still quite like it |
| [15:54:23] | stuarta: | however one of my specialities is configuration management, so complex and powerful SCM systems don't bother me |
| [15:55:58] | stuartm: | I hate to keep ragging on git, but improved merging was one of the touted benefits and yet I've run into multiple bizarre merge issues (some of which would not have caused issue with svn), so I'm genuinely baffled |
| [15:59:39] | ** stuarta blames sphery for doing a commit whilst you were re-arranging stuff ** | |
| [16:01:19] | stuartm: | stuarta: only he didn't, at least not according to the commit log |
| [16:01:34] | stuarta: | did according to the network graph |
| [16:01:38] | stuartm: | and I didn't do a 'pull' on the master branch between branching and merging |
| [16:02:29] | stuartm: | stuarta: that was on last nights changes which went without a hitch |
| [16:02:51] | stuarta: | so you branched, did you reorg in the branch and then merged back? |
| [16:02:58] | stuartm: | they were pushed just before midnight |
| [16:03:39] | stuartm: | stuarta: yup, starting with a clean master, branched, made the changes then merged back again (as has been recommended to me several times now) |
| [16:04:15] | stuartm: | since there were no changes in master between branching and re-merging I didn't need to pull before pushing |
| [16:04:34] | stuarta: | odd |
| [16:04:38] | stuarta: | that should be correct |
| [16:04:50] | stuarta: | AFAIK about git |
| [16:11:04] | danielk22 (danielk22!~danielk@115.111.88.251) has joined #mythtv | |
| [16:20:35] | stuarta: | nice diagrams that explains rebasing http://book.git-scm.com/4_rebasing.html |
| [16:23:34] | iamlindoro: | nice diagrams that highlight all that is wrong with git: http://book.git-scm.com/4_rebasing.html |
| [16:23:41] | iamlindoro: | oh, whoops, beat me to the link, my bad ;) |
| [16:24:23] | stuarta: | i beg to differ with your statement "all that is wrong with git" |
| [16:24:41] | iamlindoro: | There's a divide here that I'm just convinced we're never going to cross |
| [16:24:54] | iamlindoro: | all that is right to one group is exactly what the other group feels they are missing :) |
| [16:25:10] | stuarta: | what's wrong with what is in those diagrams? |
| [16:25:22] | stuarta: | very nice concise explanation of how it works |
| [16:25:35] | andreax (andreax!~andreaz@p57B95569.dip.t-dialin.net) has joined #mythtv | |
| [16:25:59] | ** jamesba shrugs ** | |
| [16:26:22] | jamesba: | the only time I've had problems with git have been when trying to use git-svn to do things with SVN repositories |
| [16:26:28] | iamlindoro: | stuarta: I say it mostly in jest, but my point, and I think the point to many of us who are frustrated with git, is that if the complication of the tool is such that you need a massive set of diagrams and reams and reams of documentation to get the simplest thing done, there's something inherently wrong |
| [16:26:44] | ** stuarta shrugs ** | |
| [16:26:55] | stuarta: | it's what happens when you move beyond "simple" scm |
| [16:27:13] | iamlindoro: | But I'm not willing to re-fight this battle, I'm just trying to highlight that what is what man's treasure is another man's nightmare |
| [16:27:23] | iamlindoro: | er what is one |
| [16:27:33] | stuarta: | i used to use one where the 2 devs would make independent changesets on that would conflict |
| [16:27:37] | stuarta: | both would commit |
| [16:27:53] | stuarta: | and then me as the "code master" for want of a better term |
| [16:27:58] | stuarta: | would have to make a merge commit |
| [16:28:08] | stuarta: | pulling in bits from both |
| [16:28:27] | stuarta: | to make a unified whole |
| [16:28:46] | stuarta: | this is far better |
| [16:28:55] | iamlindoro: | I'm sorry I said anything |
| [16:29:19] | iamlindoro: | We're going back to where I can just use SVN and not lose a patch every few days, so it's not worth having a fight about |
| [16:31:07] | h7251 (h7251!~h725@88-117-20-142.adsl.highway.telekom.at) has joined #mythtv | |
| [16:32:34] | ** stuarta was merely chatting ** | |
| [16:32:44] | stuarta: | can't be arsed with fighting |
| [16:33:57] | stuarta: | i don't actually understand how people "lose stuff" every few days? |
| [16:34:57] | iamlindoro: | git stash, git pull, git stash pop |
| [16:35:05] | iamlindoro: | has shredded multiple days of work several times on me |
| [16:35:16] | stuarta: | hmmm, it works fine when i try it |
| [16:35:23] | iamlindoro: | when it can't reconcile the merge on the way back in, but loses the patch somewhere in there |
| [16:36:15] | iamlindoro: | It hasn't happened in a week or two because I've simply given up and started working around git by just creating my own diffs and reapplying them |
| [16:36:49] | stuarta: | use quilt then |
| [16:37:41] | iamlindoro: | I don't have to use quilt-- we just have to convert back to SVN, and then when SVN decides it can't handle a merge I can just open my editor right then and there, correct the conflicts, and get on with it |
| [16:37:56] | iamlindoro: | and quilt is just another way of working around git |
| [16:38:20] | iamlindoro: | which adds more complication-- if I've got to keep git from destroying my patches, might as well choose the simple solution |
| [16:38:24] | stuarta: | i used it with svn |
| [16:38:52] | iamlindoro: | That's cool, and I'm glad it works for you-- I just don't need it to handle simple conflicts on an update |
| [16:39:26] | iamlindoro: | I know a lot of people are happy with quilt-- and this might make me a/the moron, but I've managed to have quilt destroy things on me the couple of times I've tried to use it too |
| [16:39:43] | iamlindoro: | so for my simple-minded purposes, a simple diff does the trick and is 100% safe |
| [16:39:45] | stuarta: | tbh, it's the same concept as stash |
| [16:40:13] | stuarta: | i found it most useful to compartmentalize my changes |
| [16:40:41] | stuarta: | so i could create a run of 4 or 5 patches to fix/improve things |
| [16:42:01] | stuarta: | made it much easier to refresh against head, rather than having to fix merge conflicts |
| [16:42:18] | stuarta: | refreshing is by far easier |
| [16:42:38] | stuarta: | i guess i move the problem away from fixing conflicts |
| [16:42:46] | stuarta: | i don't do conflicts |
| [16:43:02] | stuarta: | hence the whole rebase thing makes perfect sense to me |
| [16:43:14] | stuarta: | it's the equiv of my svn + quilt use |
| [16:45:09] | stuartm: | let's not reignite the git wars, the first one was bloody enough I don't want a second which ends with nukes being dropped |
| [16:46:00] | iamlindoro: | I don't want any more fights either |
| [16:46:38] | iamlindoro: | I am happy with blaming myself for being too dense to comprehend the advantages of git, or of somehow having screwed myself repeatedly with git, so long as the end result is something I can work with and trust again |
| [16:47:50] | elmojo: | nukes are already being dropped in one of our critical libraries – no more wars, please |
| [16:48:19] | ** stuarta hums quietly to self ** | |
| [16:48:58] | stuarta: | we will get there in the end |
| [16:49:24] | ** stuarta decides a nice cup of tea is in order ** | |
| [16:53:11] | ** elmojo turns off caps lock (that was close) ** | |
| [16:56:09] | ** stuarta makes a nice cuppa for everyone ** | |
| [16:56:44] | elmojo: | stuarta: that patch from Jiri only looks like it will target livetv... didn't you mention you have a lock-up? |
| [16:56:55] | stuarta: | not a lockup no |
| [16:57:09] | stuarta: | my 0.24 frontend show stuttering on playback |
| [16:57:16] | stuarta: | did this on 0.23 too, but 0.22 was fine |
| [16:57:19] | elmojo: | consistent? |
| [16:57:31] | elmojo: | and persistent? |
| [16:57:41] | stuarta: | not exactly |
| [16:58:03] | stuarta: | play something that stutters, jump back 5s and it'll play the same bit of video flawlessly |
| [16:58:10] | stuarta: | what i did notice |
| [16:58:56] | stuarta: | is when it was in this situation, one of the threads (the highest cpu consumer, so i'm guessing the decode thread) was quite often in futex_wait |
| [16:59:04] | stuarta: | when it was working fine it wasn't |
| [16:59:58] | stuarta: | which smells to me like we may have a minor mutex wait, that doesn't show up on higher cpu spec boxes |
| [17:00:28] | stuarta: | top reports cpu as 75% idle |
| [17:00:32] | ** Beirdo yawns ** | |
| [17:00:48] | Beirdo: | oy. working late, then getting in early... is a nasty combo |
| [17:02:59] | elmojo: | stuarta: interesting – did you trace the code to find how we where getting in the futex_wait? are you sure it wasn't due to the decoder waiting on data from the ringbuffer? |
| [17:03:27] | elmojo: | and is it a remote frontend? |
| [17:03:36] | stuarta: | is the ringbuffer involved on recording playback? |
| [17:03:51] | stuarta: | remote frontend / nfs based recordings / wired net |
| [17:04:12] | stuarta: | anyway have to go get little man from nursery, so i'll let you cogitate on that |
| [17:05:38] | elmojo: | ringbuffer is what we use in replace for the default file IO in the ffmpeg demuxer – so yes we always use the ringbuffer for playback |
| [17:08:37] | stuartm: | ok, my reign of destruction is over for now |
| [17:08:57] | iamlindoro: | Law of conversation of libraries |
| [17:09:08] | iamlindoro: | libs can't be created or destroyed, only transformed |
| [17:09:13] | stuartm: | still work to be done in libmyth obviously, but I've had enough for now |
| [17:09:24] | stuartm: | conversion, surely? |
| [17:09:47] | iamlindoro: | er conservation |
| [17:09:49] | stuartm: | heh, conservation |
| [17:10:00] | iamlindoro: | fingers went ahead of brain |
| [17:10:05] | stuartm: | ditto |
| [17:10:22] | elmojo: | stuarta: in a nutshell, it sounds like the decoder is getting starved so either an issue with the ringbuffer code or you network might have become unstable |
| [17:11:10] | stuartm: | I'm seeing what appears to be a decoder starvation issue with dvd playback on one frontend |
| [17:11:48] | elmojo: | I notice an occasional stutter every few minutes on one of me remote frontends which plays back fine if I replay |
| [17:11:53] | stuartm: | and that's local, from a disc in the drive |
| [17:12:08] | elmojo: | maybe ringbuffer related then |
| [17:12:37] | elmojo: | there are some #if 1 optimizations in RingBuffer.cpp you could disable and see if it helps or not |
| [17:13:12] | elmojo: | would be an easy experiment to try |
| [17:13:23] | jarle (jarle!~jarle@70.84-234-133.customer.lyse.net) has quit (Remote host closed the connection) | |
| [17:13:55] | elmojo: | actually only one #if 1 in there now |
| [17:14:12] | stuartm: | well it would be, if that frontend wasn't using packages :) |
| [17:14:47] | stuartm: | i.e. I can try it, but not immediately, I'd need to find some time when I can play with it |
| [17:16:03] | stuartm: | I was hoping someone else might have seen the problem so that I wouldn't have to mess with a production box ;) |
| [17:16:05] | jarle (jarle!~jarle@70.84-234-133.customer.lyse.net) has joined #mythtv | |
| [17:17:46] | jarle (jarle!~jarle@70.84-234-133.customer.lyse.net) has quit (Remote host closed the connection) | |
| [17:19:26] | h7251 (h7251!~h725@88-117-20-142.adsl.highway.telekom.at) has quit (Ping timeout: 276 seconds) | |
| [17:19:56] | iamlindoro: | kormoc: Did we get an OK back from OSUOSL that we can host our samples there in the short term? Heck, if we can just put them there during development then work can continue |
| [17:25:48] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [17:26:23] | jarle (jarle!~jarle@70.84-234-133.customer.lyse.net) has joined #mythtv | |
| [17:36:56] | gigem_ (gigem_!~david@host137.12.intrusion.com) has quit (Ping timeout: 250 seconds) | |
| [17:36:56] | jamesba (jamesba!~jamesba@132.185.140.26) has quit (Quit: Leaving) | |
| [18:00:44] | kormoc: | iamlindoro, go for it |
| [18:08:57] | iamlindoro: | k, pushing them to my ~ now, someone will need to get them to the sync dir thereafter-- thanks kormoc |
| [18:09:01] | Captain_Murdoch: | kormoc, iamlindoro, what do you think about making the URL in the source code be something that gets redirected to the actual location? ie, http://services.mythtv.org/setupsamples/the_hd_sample/ which we redirect to ftp://ftp.osuosl.org/mythtv/setupsamples/the_hd_sample.mp4 that way we can move it later if we need to without breaking old FE's. we can put in a php script to redirect users to differnt places, etc.. |
| [18:09:14] | iamlindoro: | Bah. ,I can't log in to svn.mythtv.org any more?? |
| [18:09:20] | Captain_Murdoch: | it's a new server |
| [18:09:28] | _MOh_ (_MOh_!~moh@41.105.62.26) has joined #mythtv | |
| [18:09:37] | Captain_Murdoch: | I can take care of it and I have the samples downloaded already from you. |
| [18:09:49] | iamlindoro: | OK, would be appreciated, thanks |
| [18:10:00] | iamlindoro: | would also be good to get everyone's ssh access back up, it seems like |
| [18:10:09] | Captain_Murdoch: | if they're going on the ftp mirror they need to be on the www sever anyway, not svn/themes/services since osu rsyncs from the www server. |
| [18:10:36] | iamlindoro: | OK... well, have always sent files there for someone to move to the ftp rsync dir |
| [18:10:52] | Captain_Murdoch: | may need to rethink the vserver for svn if we start granting ssh to lots of people. |
| [18:12:10] | Captain_Murdoch: | yeah, they had to copy them to www server. what do you think about the redir? I can go ahead and put samples in the rsync dir for pickup as ftp://ftp.osuosl.org/mythtv/blah/the_hd_sample.mp4, but what should 'blah' be? 'videosamples'? 'videosetup'? setupsamples? |
| [18:13:57] | iamlindoro: | I like videosamples |
| [18:14:17] | Captain_Murdoch: | ok, one other option... videotest? |
| [18:14:40] | iamlindoro: | I have toyed with the idea of (if bandwidth and storage were no object) having a dropdown menu of various types of files, so in theory it could grow to greater than two in the future if we wanted |
| [18:14:52] | iamlindoro: | I like just videosamples or samples |
| [18:16:22] | Captain_Murdoch: | ok, will go in videosamples when finished uploading. rsync in ~11 hours. what do you think about a redirect? If we do decide to move later, I'd rather not break old FE's. |
| [18:16:48] | Captain_Murdoch: | plus, redirect lets us see how many are downloading since we have no view into ftp.osuosl.org |
| [18:17:01] | iamlindoro: | I like the redirect idea |
| [18:17:09] | iamlindoro: | OK with me across the board |
| [18:18:16] | Captain_Murdoch: | and MythDownloadManager's user agent is "MythDownloadManager v0.25.20110119–1" so we can run stats across versions if we want. |
| [18:24:10] | sphery: | great, now The Man is tracking my MythTV... ;) |
| [18:25:42] | kormoc: | Captain_Murdoch, re:redirect script, I like the idea personally |
| [18:26:17] | _MOh_ (_MOh_!~moh@41.105.62.26) has left #mythtv ("Konversation terminated!") | |
| [18:32:21] | Mousey (Mousey!~wtfisme@ross154.net) has joined #mythtv | |
| [18:33:27] | Mousey (Mousey!~wtfisme@ross154.net) has quit (Remote host closed the connection) | |
| [18:33:51] | Cougar (Cougar!~cougar@kkk.version6.net) has quit (Ping timeout: 240 seconds) | |
| [18:33:52] | Mousey (Mousey!~wtfisme@ross154.net) has joined #mythtv | |
| [19:04:31] | dekarl1 is now known as dekarl | |
| [19:04:33] | stuartm: | "Cannot apply to a dirty working tree, please stage your changes" << well that's killed git stash for me |
| [19:04:46] | stuartm: | back to patches |
| [19:11:25] | stuarta: | elmojo: i actually think that it not decoder starvation |
| [19:11:29] | kth (kth!~kth@dyndsl-080-228-178-139.ewe-ip-backbone.de) has joined #mythtv | |
| [19:11:46] | stuarta: | since there are 2 main threads relating to playback |
| [19:12:00] | stuarta: | the decoder, and the display thread |
| [19:12:29] | stuarta: | i had 1 thread in drm_<something> which would be the display thread |
| [19:13:26] | stuarta: | 1 thread that would get stuck in futex_wait, this would be the decoder thread |
| [19:14:21] | stuarta: | i was getting stuttering when the 1 thread was in futex_wait, but not when it wasn't |
| [19:14:58] | stuarta: | so my hypothesis is that it's hitting a mutex which is stopping it from decoding more frames when it should be busy filling the display pipe |
| [19:15:08] | stuarta: | make any sense? |
| [19:16:53] | stuarta: | if you have a situation where you get stuttering, run top and hit 'f' then 'y' to add the function the thread is waiting in. |
| [19:16:58] | ** stuarta toddles off for dinner ** | |
| [19:25:38] | elmojo: | stuarta: yes, I follow you but not sure why/how the decoder thread would stop like that |
| [19:27:44] | elmojo: | maybe you could provide a dump of the stuck thread so maybe we could figure out what resource it's waiting on |
| [19:42:05] | kth1 (kth1!~kth@dyndsl-080-228-178-139.ewe-ip-backbone.de) has joined #mythtv | |
| [19:42:05] | kth (kth!~kth@dyndsl-080-228-178-139.ewe-ip-backbone.de) has quit (Read error: Connection reset by peer) | |
| [19:45:42] | kth (kth!~kth@dyndsl-080-228-178-139.ewe-ip-backbone.de) has joined #mythtv | |
| [19:45:42] | kth1 (kth1!~kth@dyndsl-080-228-178-139.ewe-ip-backbone.de) has quit (Read error: Connection reset by peer) | |
| [19:57:28] | stuarta: | elmojo: i'll see what i can do |
| [20:01:22] | stuarta: | i'm going to have to eyeball the code and see if i can work out how such a thing is possible |
| [20:01:57] | stuarta: | i was hoping there might be something of use in the livetv chaining issue currently on the mailing list, but i don't think so |
| [20:02:48] | Cougar (Cougar!~cougar@kkk.version6.net) has joined #mythtv | |
| [20:05:27] | gigem_ (gigem_!~david@host137.12.intrusion.com) has joined #mythtv | |
| [20:07:33] | kth1 (kth1!~kth@dyndsl-080-228-178-139.ewe-ip-backbone.de) has joined #mythtv | |
| [20:08:07] | kth (kth!~kth@dyndsl-080-228-178-139.ewe-ip-backbone.de) has quit (Quit: Leaving.) | |
| [20:22:00] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 260 seconds) | |
| [20:26:56] | wagnerrp: | Captain_Murdoch: and the backend automatically polls the list of themes once per day? |
| [20:27:11] | Captain_Murdoch: | not yet, but I'll commit that soon. |
| [20:28:24] | Captain_Murdoch: | it's in my tree just doing final tweaking of that and the notifier in the limited time I have. |
| [20:39:35] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [20:43:25] | wagnerrp: | well that would give a nice anonymous tally of users and versions |
| [20:43:36] | wagnerrp: | (of people who are running a modern version anyway) |
| [20:47:50] | kth (kth!~kth@dyndsl-080-228-178-139.ewe-ip-backbone.de) has joined #mythtv | |
| [20:47:50] | kth1 (kth1!~kth@dyndsl-080-228-178-139.ewe-ip-backbone.de) has quit (Read error: Connection reset by peer) | |
| [20:56:04] | Beirdo: | okolsi: ping |
| [21:21:29] | dekarl1 (dekarl1!~deKarl@e180146128.adsl.alicedsl.de) has joined #mythtv | |
| [21:22:58] | Captain_Murdoch: | wagnerrp, yeah, didn't think about that aspect. :) |
| [21:23:45] | Captain_Murdoch: | might want to make that into a page we can log stats from easily as well then. |
| [21:23:50] | dekarl (dekarl!~deKarl@e180137134.adsl.alicedsl.de) has quit (Ping timeout: 276 seconds) | |
| [21:28:37] | sphery: | stuarta: I'm modifying channel.xmltvid to be 255 chars--tv_grab_es_laguiatv in Spain has a listings provider using strange encoding that results in at least one xmltvid > 64 chars. dekarl1 (of XMLTV) suggested 255 chars since xmltvid is constructed similarly to hostnames. If I increase that, do you want me to also increase channel.default_authority and/or dtv_multiplex.default_authority or anything? |
| [21:29:12] | stuarta: | no they are fine |
| [21:29:24] | sphery: | thx |
| [21:31:24] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Read error: Connection timed out) | |
| [21:39:04] | h7251 (h7251!~h725@62-47-248-128.adsl.highway.telekom.at) has joined #mythtv | |
| [21:49:54] | stuartm: | iamlindoro: were you able to verify that media status events were working (-v media) and providing the information you wanted? |
| [21:53:22] | dekarl1 is now known as dekarl | |
| [21:53:29] | gigem_ (gigem_!~david@host137.12.intrusion.com) has quit (Ping timeout: 240 seconds) | |
| [21:53:32] | davide_ (davide_!~david@host137.12.intrusion.com) has joined #mythtv | |
| [21:53:37] | davide_ (davide_!~david@host137.12.intrusion.com) has quit (Changing host) | |
| [21:53:37] | davide_ (davide_!~david@mythtv/developer/gigem) has joined #mythtv | |
| [21:54:45] | sphery: | stuartm: did you notice my question about UNDO/REDO bindings for #8901? Should they go in TV Editing or would it make sense to make them Global (where we could eventually use them in, for example, even text areas, etc.)? |
| [21:55:13] | bbc581 (bbc581!~bbc581@74-129-133-90.dhcp.insightbb.com) has quit (Quit: Got to keep moving!!) | |
| [21:56:05] | stuartm: | global I guess |
| [21:56:59] | stuartm: | bind them to Ctrl-z, Ctrl-y by default and I'm sure it would make a lot of people happy |
| [22:02:38] | sphery: | We currently have TV Playback/PREVSOURCE mapped to Ctrl-Y... how should I handle that? |
| [22:02:59] | sphery: | stuartm: ^^^ |
| [22:04:58] | HackeMate (HackeMate!~hXm@31.Red-83-53-191.dynamicIP.rima-tde.net) has joined #mythtv | |
| [22:05:03] | HackeMate: | hello |
| [22:06:19] | HackeMate (HackeMate!~hXm@31.Red-83-53-191.dynamicIP.rima-tde.net) has left #mythtv ("Saliendo") | |
| [22:07:22] | kth (kth!~kth@dyndsl-080-228-178-139.ewe-ip-backbone.de) has quit (Quit: Leaving.) | |
| [22:07:22] | kth1 (kth1!~kth@dyndsl-080-228-178-139.ewe-ip-backbone.de) has joined #mythtv | |
| [22:07:32] | sphery: | chances are that we won't need UNDO/REDO in TV Playback, but... |
| [22:09:12] | stuartm: | sphery: I'd unbind it ... |
| [22:09:52] | stuartm: | REDO clearly has more 'right' to that mapping |
| [22:10:11] | sphery: | cool--probably few using it these days... I'll remove the default for PREVSOURCE, and if it's still bound to default, I'll unbind it--if they've changed it to anything other than the default, I'll leave it and they can fix the conflict |
| [22:10:29] | stuartm: | and Ctrl-Y isn't really intuitive for PREVSOURCE – if anything you'd expect that to be bound to Ctrl-Z |
| [22:10:48] | sphery: | thanks for the input... wasn't sure how to handle that. |
| [22:11:33] | stuartm: | considering we now have 'browse across tuners' and an OSD menu which gives access to all those options PREVSOURCE is a minority-interest binding |
| [22:13:07] | kth (kth!~kth@dyndsl-080-228-178-139.ewe-ip-backbone.de) has joined #mythtv | |
| [22:13:08] | kth1 (kth1!~kth@dyndsl-080-228-178-139.ewe-ip-backbone.de) has quit (Read error: Connection reset by peer) | |
| [22:14:30] | sphery: | agreed |
| [22:16:58] | iamlindoro: | stuartm: I'm sorry, the only computer I manage to get near lately is my work one (well, and my mythbox via telnet), I haven't tried yet |
| [22:17:06] | iamlindoro: | ahah, telnet.. I mean ssh |
| [22:21:46] | kth1 (kth1!~kth@dyndsl-080-228-178-139.ewe-ip-backbone.de) has joined #mythtv | |
| [22:21:46] | kth (kth!~kth@dyndsl-080-228-178-139.ewe-ip-backbone.de) has quit (Read error: Connection reset by peer) | |
| [22:22:23] | Jordack (Jordack!~jordack@h69-131-44-221.mdsnwi.tisp.static.tds.net) has quit () | |
| [22:27:12] | stuartm: | iamlindoro: no worries, I'll give it a spin here |
| [22:35:52] | kth (kth!~kth@dyndsl-080-228-178-139.ewe-ip-backbone.de) has joined #mythtv | |
| [22:35:58] | kth1 (kth1!~kth@dyndsl-080-228-178-139.ewe-ip-backbone.de) has quit (Quit: Leaving.) | |
| [22:36:35] | stuartm: | is anyone here disabling media monitoring and for what reasons? Going forward we're going to want to integrate media status changes more tightly with the UI etc, so I need to know what bugs might need fixing before we can remove the setting and make it 'always on' |
| [22:37:14] | iamlindoro: | I have at various times had it disabled |
| [22:37:48] | iamlindoro: | It has a tendency to decide that various empty flash drive slots are CD-ROMs and prompt me to pick one every single time on startup |
| [22:38:15] | iamlindoro: | Not only are they not CD drives, they're not mounted and have nothing loaded in them |
| [22:38:39] | iamlindoro: | I also seem to recall a very long time ago seeing it go into some odd polling mode where it affected playback |
| [22:39:08] | iamlindoro: | All or none of the above may still be valid, it's been a while |
| [22:39:39] | sphery: | I've disabled it primarily because I'm a control freak who doesn't like his computer doing things it's not explicitly told to do. The CD of images I put in the drive may not be for MythTV to use, etc... |
| [22:40:22] | sphery: | That said, I could live with changes that make it mandatory (and wouldn't be upset over losing the ugly maze of inter-related settings that it takes to disable it successfully and completely) |
| [22:40:48] | stuartm: | sphery: ok, that's probably something to deal with at the plugin level – settings to prevent auto-loading/importing of files from newly inserted media |
| [22:41:47] | stuartm: | i.e. it's not implicitly a problem with the media monitor but with mythgallery or another plugin |
| [22:42:43] | sphery: | Yeah, we have those, now, but since I disabled it in all of them, I also just completely disabled it. Main issue we seem to have, now, with media monitoring is choosing the right devices to monitor (as iamlindoro referenced). We now have libudev code for those who have its headers installed, but for others, it falls back to the same broken code we had before (and I don't know for sure that the libudev code is any smarter about picking the ... |
| [22:42:49] | sphery: | ... right stuff). |
| [22:44:22] | sphery: | and, really, I could live with the computer's automatically doing things if it were reliable and trustworthy--and the best way to get it there is to make us all run with it :) |
| [22:45:54] | h7251 (h7251!~h725@62-47-248-128.adsl.highway.telekom.at) has quit (Ping timeout: 250 seconds) | |
| [22:46:49] | kth (kth!~kth@dyndsl-080-228-178-139.ewe-ip-backbone.de) has quit (Quit: Leaving.) | |
| [22:49:01] | stuartm: | heh yeah, the bugs are more likely to be fixed if we force people to use it |
| [22:53:57] | stuartm: | occurs to me that one of the things I don't like about git (and yes, there are a few) is that there is not much attention given to making the UI useful – evident in the output from git push for example, you get ~7 lines of information – object counts, Delta compression, thread counts, kb (compressed) written to the remote etc all of which is worthless to me |
| [22:54:53] | stuartm: | but nowhere do they say "pushed 3 commits" or even more usefully, a one-line summary for pushed commits "pushing these 3 commits:" etc |
| [22:55:45] | sphery: | heh, yeah, that would be useful output |
| [22:59:20] | stuartm: | I'm sure that a few people are going to think I'm being pedantic, but there's no attention to the detail, to telling the end user what they really need to know or making it possible to do regular tasks with as little work as possible – it's a tool designed solely by engineers with no input from anyone who is able to see things from the ordinary users perspective :/ |
| [23:01:08] | stuartm: | I don't claim to be an expert in those things, but I think about them a lot more since I forced myself to see mythtv in that way |
| [23:03:39] | Beirdo: | nothing wrong with being pedantic. |
| [23:05:10] | Beirdo: | wonder if git push -v gives any better output (never tried it) |
| [23:06:03] | stuartm: | I'll try it the next time I push |
| [23:06:32] | Beirdo: | worth a try :) I'll give it a shot too. |
| [23:07:19] | stuartm: | though judging from the verbosity of the ordinary invocation it could be a little noisy ;) |
| [23:07:39] | Beirdo: | hehe. |
| [23:07:48] | Beirdo: | yeah, we'll have to see, I guess |
| [23:09:17] | kormoc: | I'd support ditching non-udev code paths |
| [23:11:29] | Beirdo: | would that make OSX/Windows more difficult or easier to support? |
| [23:11:45] | Beirdo: | or is that code path not even active there at all? |
| [23:11:49] | kormoc: | I mean for the linux binary |
| [23:11:53] | Beirdo: | ah :) |
| [23:12:00] | kormoc: | I don't think there's media monitoring on the other platforms at all |
| [23:12:13] | stuartm: | there is for osx |
| [23:12:15] | Beirdo: | yeah, we use udev in pretty much any distro that new enough to have a supported Qt |
| [23:12:17] | kormoc: | ahh, my mistake |
| [23:12:38] | stuartm: | don't know much about it, but we're linking in the DiskArbitration framework for OSX |
| [23:13:11] | Beirdo: | neat. Well, simplifying by removing old cruft without breaking what the code does... I'm all for :) |
| [23:15:04] | Beirdo: | our minimum requirements for things like ALSA and Qt, etc already require a fairly new setup. I don't see the harm in going with udev only (for Linux) |
| [23:15:16] | stuartm: | media monitoring is a bit busted here, it's failing to mount the disc but when I run the same commands myself they work fine |
| [23:15:41] | stuartm: | so it's some odd perms or myth_system bug I guess |
| [23:16:28] | Beirdo: | hmm. well, if you can find it as the latter, please add it to #9421 so I can look into it. :) |
| [23:16:52] | Beirdo: | unless you fix it, of course :) |
| [23:21:48] | stuartm: | Beirdo: heh, check the logic – https://github.com/MythTV/mythtv/blob/master/ . . . dia.cpp#L129 |
| [23:22:20] | Beirdo: | ahahahah |
| [23:22:23] | Beirdo: | oops |
| [23:22:45] | Beirdo: | OMG. yeah, that's an easy fix :0 |
| [23:24:04] | Beirdo: | I musta been retarded when I fixed it to use the GENERIC_EXIT_OK |
| [23:24:09] | j-rod is now known as j-rod|afk | |
| [23:25:26] | Beirdo: | you up for fixing it? ;) |
| [23:26:34] | stuartm: | you can have that honour :) |
| [23:26:43] | stuartm: | I'm off to bed |
| [23:26:48] | Beirdo: | K. |
| [23:27:57] | h7251 (h7251!~h725@62-47-248-128.adsl.highway.telekom.at) has joined #mythtv | |
| [23:34:15] | ikonia (ikonia!~mattd@unaffiliated/ikonia) has quit (Ping timeout: 240 seconds) | |
| [23:39:03] | h7251 (h7251!~h725@62-47-248-128.adsl.highway.telekom.at) has quit (Quit: Leaving.) | |
| [23:39:06] | h7252 (h7252!~h725@62-47-248-128.adsl.highway.telekom.at) has joined #mythtv | |
| [23:53:59] | h7252 (h7252!~h725@62-47-248-128.adsl.highway.telekom.at) has quit (Ping timeout: 276 seconds) | |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.
