Back to Home / #mythtv / 2007 / 03 / Prev Day | Next Day
#mythtv IRC Logs for 2007-03-12

---Logopened Mon Mar 12 00:00:34 2007
00:00|-|Nem^ [] has quit [Read error: 110 (Connection timed out)]
00:00|-|Nem^1 changed nick to Nem^
00:37|-|gnome42 [] has quit [Remote closed the connection]
00:45|-|adante [] has quit [Connection timed out]
01:09|-|czth__ [i=dbrobins@nat/microsoft/x-2ca58d3fe5d22417] has joined #mythtv
01:15|-|PFalcon [] has joined #mythtv
01:24|-|jebel [] has quit ["This computer has gone to sleep"]
01:25|-|czth_ [i=dbrobins@nat/microsoft/x-c8be965fc02b1fd1] has quit [Read error: 110 (Connection timed out)]
01:32|-|PeregrineFalcon [] has quit [Read error: 110 (Connection timed out)]
01:50|-|jebel [] has joined #mythtv
01:54|-|malban [] has quit [Read error: 110 (Connection timed out)]
01:57|-|jebel [] has quit ["This computer has gone to sleep"]
02:10|-|okolsi [n=fiottkol@unaffiliated/okolsi] has joined #mythtv
02:33|-|Cardoe [n=Cardoe@gentoo/developer/Cardoe] has joined #mythtv
02:54|-|xris [] has quit ["Leaving."]
03:10|-|robthebob [] has joined #mythtv
03:28|-|celston [] has joined #mythtv
03:45|-|kormoc [] has quit []
04:08|-|celston [] has quit ["Leaving."]
04:13|-|robthebob [] has quit [Read error: 113 (No route to host)]
04:22|-|stuarta [n=stuart@unaffiliated/stuarta] has joined #mythtv
04:26|-|degreseven [] has quit [Remote closed the connection]
04:48|-|bach_ [] has joined #mythtv
04:58|-|bach_ [] has left #mythtv ["Konversation terminated!"]
04:59|-|nbags [n=someone@] has joined #mythtv
04:59|-|nbags [n=someone@] has left #mythtv []
05:44|-|adante [] has joined #mythtv
06:07|-|DrNickRiviera [] has joined #mythtv
06:37|-|LLyric [] has quit ["Leaving"]
06:59|-|okolsi [n=fiottkol@unaffiliated/okolsi] has left #mythtv []
07:45|-|CDev_ [] has joined #mythtv
07:46|-|CDev_ [] has quit [Client Quit]
08:12|-|Cardoe [n=Cardoe@gentoo/developer/Cardoe] has quit ["Leaving"]
08:20|-|JoeBorn [] has joined #mythtv
08:46|-|Cardoe [n=cardoe@gentoo/developer/Cardoe] has joined #mythtv
09:06|-|dverzolla [] has joined #mythtv
09:06<dverzolla>Hi, has anyone using PVR-350 within output?
09:16|-|jebel [] has joined #mythtv
09:18|-|JoeBorn [] has quit [Read error: 110 (Connection timed out)]
09:19|-|knowledgejunkie [] has joined #mythtv
09:22|-|knowledgejunkie changed nick to knowledgejunkie_
09:23|-|sigger_ [] has joined #mythtv
09:25<sigger_>gbee: you around?
09:25|-|knowledgejunkie_ changed nick to knowledgejunkie
09:31|-|jgarvey [] has joined #mythtv
09:44|-|mccune [] has joined #mythtv
09:45|-|jmk_ [] has joined #mythtv
09:51|-|dverzolla [] has left #mythtv []
09:54|-|ccfiel [n=ccfiel@] has joined #mythtv
09:54<ccfiel>hello ppl. :)
09:55<ccfiel>i want to make a myVideoke plug in.
09:56<ccfiel>can somebody give me some links on how to make plug in in myth tv?
09:56<sigger_>ccfiel: check the wiki
09:57<sigger_>Under developer documentation, Building Plugins: HelloMyth.
09:58<ccfiel>sigger_: thanks im now browsing it :)
10:00<ccfiel>sigger_: have you tried building plugins?
10:00<sigger_>just got rolling working on one a few days ago. (though I may instead try to structure it as a change to an existing one)
10:21|-|jebel [] has quit ["This computer has gone to sleep"]
10:28|-|MoRpHeUz [n=morphbr@] has joined #mythtv
10:31|-|MoRpHeUz_ [n=morphbr@] has joined #mythtv
10:32|-|MoRpHeUz [n=morphbr@] has quit [Nick collision from services.]
10:32|-|MoRpHeUz_ [n=morphbr@] has quit [Client Quit]
10:34|-|ccfiel [n=ccfiel@] has quit []
10:42|-|aevil [] has joined #mythtv
10:45|-|malban [] has joined #mythtv
10:49|-|okolsi [n=mythtv@] has joined #mythtv
10:54|-|hd420 [] has left #mythtv []
11:00|-|gnome42 [] has joined #mythtv
11:02<knowledgejunkie>janneg: thanks for trac ticket #3197 with my email address
11:04<janneg>knowledgejunkie: you're welcome. but I won't change every ticket
11:05<knowledgejunkie>janneg: I appeciate it - maybe trac will be fixed instead
11:08|-|bsjeep [] has joined #mythtv
11:12<okolsi>knowledgejunkie: it seems that even thou you might not have Trac account.. you can save you name/e-mail etc. in Preferences.. and then it works better
11:12<okolsi>it populates the e.g. the e-mail automatically to the correct field
11:12<knowledgejunkie>okolsi: Thx
11:13<knowledgejunkie>okolsi: I'll give that a go
11:13<knowledgejunkie>okolsi: trac was accepting the field, then whenever a preview or post was executed, reverted it back to 'anonymous'
11:14<okolsi>yes.. I've experienced exactly the same..
11:14<okolsi>but with your e-mail in preferences.. it seems to keep it correctly in that field
11:16<okolsi>knowledgejunkie: I noticed that you asked earlier here about mythweb music back navigation.. I've got that done and hopefully will post a patch soon
11:16<knowledgejunkie>okolsi: do you see the behaviour on the prefs pages such that entering name/email and then choosing another tab forgets everything you've entered?
11:16<knowledgejunkie>okolsi: great work on the MythWeb music pages :)
11:16<okolsi>yep.. you have to save every page
11:17<okolsi>I mean.. save before you jump to another page
11:17<okolsi>silly.. but that how it seems to work
11:18<okolsi>knowledgejunkie: I'm personally listening/using mythweb music several hours every day at work.. so I'd like it to be usable at least..
11:20<knowledgejunkie>okolsi: are you open to further suggestions on mythmusic interface?
11:21<okolsi>well.. I can listen.. but I've only thought that I'm fixing just minor issues, not to do anything major.. but what have you though?
11:21<okolsi>(actually.. this is first time I ever do PHP.. so I'm just novice in this area)
11:22<knowledgejunkie>okolsi: nothing at the moment ;) Just wondering if I think of something whether I can run it by you
11:23<knowledgejunkie>okolsi: I'm not a PHP programmer (yet)
11:23<knowledgejunkie>okolsi: the preferences seem to work for populating new tickets with my details - I'll have to see if they stick when I submit a ticket in the future - thx for the tip
11:23<okolsi>okay.. feel free to contact later if you come up with some suggestions. np
11:24|-|praet [] has joined #mythtv
11:30<okolsi>janneg: have time for quick DVB CI issue?
11:32|-|beavis [] has joined #mythtv
11:32|-|malban [] has quit [Read error: 104 (Connection reset by peer)]
11:34|-|xris [] has joined #mythtv
11:50<janneg>okolsi: yes
11:57|-|MoRpHeUz [n=morphbr@] has joined #mythtv
12:05<okolsi>janneg: very quickly.. CAM module sends "menu close" or similar commands to Myth.. which are not currently supported. This produces just error log, nothing serious
12:06<okolsi>is it okay if I add just a simple parsing of this menu close command so that logs get cleaner?
12:06<okolsi>I actually already did, but just thinking whether I should put this into a ticket
12:16<janneg>okolsi: it creates something different than DVBCAM messages?
12:23<knowledgejunkie>xris: using the new script, how does one go about submitting patches for new xmltvids without affecting my DB setup?
12:24<xris>knowledgejunkie: huh?
12:24<gbee>knowledgejunkie: you don't - if the icons are on lyngsat then you're fine, otherwise submit them to lyngsat
12:24<xris>you just run the script, it sends data about your channels back to the server
12:25<knowledgejunkie>xris: what about for channels available via XMLTV with xmltvids that I do not use, but should be available for other users?
12:26<gbee>the next time someone with those xmltvids in their table runs the icon grabber they'll be asked to pick the matching icon from a list (generated from info on the lyngsat website) and then the icon will be matched against the xmltvid for future use
12:26<xris>knowledgejunkie: then other users will send their into to the server
12:27[~]xris heads to work
12:27|-|xris [] has quit ["Leaving."]
12:28<knowledgejunkie>xris: so there's no way to update the server directly? I was trying to be helpful so that whenever I update the XMLTV grabber, I can update the service.mythtv DB at the same time
12:28<knowledgejunkie>oh well :)
12:29|-|stuarta [n=stuart@unaffiliated/stuarta] has quit ["later"]
12:29<GreyFoxx>xris: Any idea what I need to do to get my listings page under mythweb to not be off by an hour? I know the PC is fine, I've restarted apache as well to make sure it got the correct timezone
12:30<okolsi>janneg: sorry, got to go again.. but they seem to be valid CAM messages that just are not taken into account.. and then fall of from one switch/case.. into ERROR print
12:31<okolsi>janneg: I'll get more details and get back to you later
12:34|-|foxhunt [] has joined #mythtv
12:36|-|jebel [] has joined #mythtv
12:40<sigger_>gbee: is code that interacts with the music player (decoder I guess) primarily located in playbackbox.cpp?
12:41<sigger_>great. and does the code check in on the decoder from time to time?
12:42<gbee>that I don't know - I've mostly been working on the scanner and metadata areas of the code
12:44<sigger_>ah ok. may not be so bad to retrofit existing code to use mpd. No reason a little extra #ifdef'ing couldn't make it compile time swithable.
12:45<sigger_>it may be a little different in how they run and are monitored tho. Ideally I will be able to check in on mpd - eg once a second to see which song its playing, if its been paused. less frequently, see if the onscreen portion of the playlist has changed.
12:47|-|malban [] has joined #mythtv
12:50|-|MoRpHeUz [n=morphbr@] has quit [Read error: 104 (Connection reset by peer)]
12:50<gbee>a quick glance suggests we set up various functions as listeners - in other words the decoder posts changes back to playbackbox rather than playbackbox polling for changes
12:51<gbee>anyway, I'm off to eat dinner
12:51<sigger_>mmm, that's what I suspected. k, thanks
12:52|-|kormoc-laptop [] has joined #mythtv
12:55<gbee>a quick thought - you might consider creating a new decoder instead of modifying playbackbox, the decoder would handle the interface to mpd including polling for changes etc
12:55<sigger_>hehe, funny you say that. Been thinking the same.
12:56<gbee>would be cleaner code-wise
12:56<sigger_>much. just have to deal with some of the structural differences (if any).
12:56<sigger_>thanks for giving it some thought. I appreciate it
13:14|-|kormoc-laptop changed nick to kormoc
13:21|-|jebel_ [] has joined #mythtv
13:21|-|jebel [] has quit [Read error: 60 (Operation timed out)]
13:34|-|eskil [] has joined #mythtv
13:36<eskil>gbee, you there ?
13:37<eskil>question about changeset 12872.
13:37<eskil>You reset the output before you stop the decoder.
13:37<eskil>Was that intentional ?
13:38<eskil>I don't get it.
13:38<eskil>Wouldn't that give the decoder a small window of time to still pump samples and reconfigure the output ?
13:39<gbee>reseting the output clears the audio buffer - otherwise it would continue outputting what remained in the buffer
13:39<gbee>ahh right I seem what you mean
13:40<eskil>Sounds like what you want is to simultaneously stop the decoder and freeze the output.
13:40<eskil>Ie. pause the output, stop the decoder, then reset the output ?
13:42|-|robthebob [] has joined #mythtv
13:43|-|GBee1 [] has joined #mythtv
13:44|-|xris [] has joined #mythtv
13:45<GBee1>sorry about that, KDE/Konq hangs my laptop every time I browse my Development folder (and I keep forgetting that it does)
13:45|-|gbee [] has quit [Nick collision from services.]
13:45|-|GBee1 changed nick to gbee
13:46<gbee>probably missed what was said in the last ~6 minutes
13:46<eskil>gbee, aces, can I offer you a link to gnome/nautilus :-)
13:46<eskil>Sounds like what you want is to simultaneously stop the decoder and freeze the output.
13:46<eskil>Wouldn't that give the decoder a small window of time to still pump samples and reconfigure the output ?
13:46<eskil>That's what you missed.
13:47<eskil>Ie. pause the output, stop the decoder, then reset the output ?
13:47<gbee>calling stopDecoder after reseting the output wasn't intended - kinda got left that way by accident as I was experimenting with different approaches
13:48<eskil>It makes sense in that you kinda want the audio to stop as soon as a stop is requested, but I've seen the output left in a unreset state, causing the next playback to have a short blurp of the previous audio.
13:49<praet>sorry to interrupt. I would like to learn more abut submitting to svn. in particular i translated italian for mythweather plugin
13:49<eskil>I think just doing "output->pause(); stopDecoder(); output->reset(); if paused unpause()" fixes it.
13:49<gbee>I don't think it's really KDE/Konqs fault so much as the fact I'm running some bleeding edge packages
13:51<gbee>eskil: I don't think my machine was fast enough to experience that bug :)
13:53<eskil>gbee, I think you'd see it more on slower machines, especially with certain shoutcast patches that might be slower at stopping the decoder that you'd expect...
13:54<gbee>the unpause isn't entirely necessary as play does that - although if you can think of a scenario where we wouldn't call play after stop then I'll do it anyway
13:55<xris>gbee: ff?
13:55<xris>rw, next, prev...
13:55<eskil>gbee, user pressing sotp ?
13:56<gbee>let me just test swapping those around then
13:56<gbee>xris: ?
13:57|-|kali67 [] has joined #mythtv
13:57<gbee>eskil: yeah, but after pressing stop they either press play or exit - there isn't another action where the output being paused might be a problem, at least not that I can see
13:58<xris>gbee: you asked about things done after stop that weren't play
13:58<eskil>gbee, oh I see what you mean, duh, you're right.
13:58<gbee>xris: none of those actions calls stop first
14:00<gbee>xris: ahh I was talking in terms of the function 'play' in mythmusic, rather than pressing 'play' on a remote/keyboard etc
14:00<gbee>next/prev etc all call 'play'
14:00<praet>thanks gbee
14:03<gbee>it wouldn't hurt to unpause in stop, so I could just do it anyway - avoids future bugs
14:03<xris>gbee: I was thinking of things the USER could do after pressing stop
14:04<eskil>gbee, coolness, I'll not file bugs+patches+stuff then.
14:05<gbee>xris: I phrased the question badly, my fault
14:08|-|l-case [] has joined #mythtv
14:08<gbee>the sooner I get mythmusic streaming from the backend the better
14:09<gbee>sick and tired of seeing the error "Decoder error. DecoderMAD: Failed to open input. Error 5."
14:09<eskil>gbee, what kind of stream ?
14:09<gbee>because my laptop has failed to mount the nfs share correctly
14:12<gbee>well more of a file-transfer really and tbh I don't know how well it'll work, but the new upnp/xml methods provide a means to fetch music files across http
14:12<gbee>so I was going to experiment with using that instead of requiring that the files be local
14:12<eskil>gbee, I've been looking at that, but I didn't see a client side implementation, only the server side stuff.
14:13<eskil>gbee, using upnp for mythmusic would be aces for so many reasons.
14:14<sigger_>since you guys are talking about it, what is the upnp hotness all about?
14:14<gbee>there isn't a client side atm, but for the sake of experimenting or even an initial implementation I can simply open up a tcp/http socket and ask the backend for the file
14:15<gbee>urls are in the form http://backend:6445/getMusic?Id=12345
14:15<sigger_>so why is that neccesarilybetter than just accessing mounted files?
14:16<gbee>hell QT *may* even all URLs as file paths in QFile which would be cool
14:16<gbee>simplifies setup and configuration
14:16|-|j-rod [i=jarod@nat/redhat/x-5a13d49cc9fb0696] has quit [Read error: 110 (Connection timed out)]
14:18<sigger_>true, no mounting. but, thinking of my own rig, I have to mount anyway for mythvideo. the streamer is/will be quick enough to stream DVD quality video?
14:19<gbee>sigger_: in the case of mythtv it already is fast enough to stream HD quality
14:20<sigger_>incidentally, in ampache music server prog we would up changing over to url based requests for files. tho not something I was involved in really.
14:20<gbee>well I say that, but someone might now point out that for HD you need to mount the recordings directory and use local access
14:21|-|j-rod [i=jarod@nat/redhat/x-8634c1a4e588f8fc] has joined #mythtv
14:21<sigger_>ah yeah, TV (including I guess HDTV) is done by streaming
14:21<eskil>sigger_, for non HD video upnp would also work. It's fully speced out for video media as well.
14:21|-|CDev_ [] has joined #mythtv
14:21<eskil>and HD would probably work on a fast-as-hell network.
14:21<eskil>But I never quite figured out why upnp was cooler than zeroconf.
14:22[~]eskil has flashbacks to betamax/vhs crossfire...
14:23<Sembiance>HD trocks
14:24<gbee>eskil: tbh what I know of uPnP/zeroconf etc would be shorter than this sentance if written down
14:24<Sembiance>I can record up to four HDTV streams and two analog streams at once on my MythTV Server ;)
14:26<eskil>gbee, they're very much the same (zeroconf = rendezvous = daap = itunes), it's kinda mostly a question as to which company you want to back.
14:26<kali67>Sembiance: can you share your Hardware setup ? What capture cards are you using ?
14:28<gbee>in #mythtv-users, please :)
14:30<eskil>gbee, about urls, but just accessing the music isn't really enough. There's also all the browsing/searching stuff.
14:31<eskil>gbee, I've been working on adding multiple stores to mythmusic since 1) shoutcast streams aren't files 2) dammit I want to access my ipod. And for that I've kinda adopted the upnp style of searching/browsing, since that would make it easy to add a upnpstore to mythmusic.
14:31<gbee>ffs, brb kopete needs a slap
14:31<CDev_>eskil: I choose to implement upnp because I have hardware players that 'just work' with it. Since the backend has the upnp stack now, it just makes sense to use where possible,
14:31<gbee>browsing searching can all be done using the info in the database
14:32<gbee>obviously scanning is out of the question though
14:32<eskil>CDev_, absolutely, there's more upnp devices out there then zeroconf, and besides politics, don't think there's a whole lot of reason to prefer zeroconf.
14:33<eskil>gbee, but stores won't all use the same db, ie. an ipod has it's own database, as would a upnp media server, and an audio cd would have none.
14:33<sigger_>using upnp, there's no way to pull tags from a (music) file absent DL'ing the file tho, is there? mpd plays urls fine, but there's no tag info until it starts playing.
14:33<gbee>having moved the directory info into the database, and with the albumart info also going into a table the only time we need direct access to the file system from mythmusic is during scanning
14:34<sigger_>unless of course one wanted to use a player other than that in mythmusic ;)
14:35<eskil>sigger_, all the necessary data would be available via the upnp browse/search queries. Great for files that don't have metadata (ie. video/wav).
14:36<sigger_>eskil: reply with tag data is in xml?
14:36<gbee>eskil: I'm talking in terms of the primary music collection - what you've listed are different cases and at the moment only one is even supported (CDs)
14:36<eskil>gbee, yes, and that's great for the mythbackend acting as a upnp media server, but it doesn't help when ie. accessing a ipod.
14:37<eskil>sigger_, yes, as everyone else, they think that xml is great for protocols, if you like a boolean being around 24 bytes of wiredata... *sigh*
14:37<eskil>gbee, yup, but I've got 4 stores in my branch, myth db, audio cd, shoutcast (in myth db...) and ipod.
14:38<sigger_>eskil: I'm not lauding it or damning it; I'm just trying to figure out how to integrate what I'm trying to achieve into the potential future access method
14:38<gbee>xml is cumbersome for protocols and rather pointless at that
14:38|-|CDev [] has quit [Read error: 110 (Connection timed out)]
14:39<gbee>eskil: I've got to say I'm not really following you - of course if you attach your ipod to the frontend it should/will be able to access it directly
14:39<eskil>gbee, xml is the most retarded encoding for protocols, I'm sure it's a conspiracy that's backed by vendors...
14:40<CDev_>gbee, eskil: xml is bloated, however, it survives changes and works across achitectures better than a more compact/binary protocol.
14:40<eskil>sigger_, yeah. Upnp just provides browse/search as in "list the first five items in album 5", and then it returns the metadata.
14:41<gbee>I'll even be leaving the option to mount a remote storage location in the code for those that want it for any reason, I'm just planning on removing the need for 99% of users
14:41<eskil>CDev_, I'm just oldschool and still think BER is the hot shit for arcane reasons (I also drive a horse carriage, use smoke signals and haven't heard of google)
14:42|-|foxhunt [] has quit [Read error: 104 (Connection reset by peer)]
14:42|-|gbee [] has quit [Remote closed the connection]
14:42|-|gbee [] has joined #mythtv
14:42<eskil>guess gbee used kde/konq again...
14:44<eskil>gbee, yes, a user would expect to connect an ipod and see all the music. What you've done (which is great!) is speed up the case where the storage is the myth db, but some day the more common case might be using a upnp device or portable blingbling device.
14:44<gbee>no, just restarting kopete (also a little buggy in head)
14:46<gbee>eskil: sure, but what I'm doing now isn't going to make that any harder
14:46<eskil>gbee, not saying that.
14:47<gbee>in which case I'm hopelessly lost
14:47<eskil>gbee, you're making the existing stuff faster, which makes me and my 30K-40K track collection happy.
14:47<eskil>gbee, I'm actually not sure what we're talking about either. Except I think we both like upnp ?
14:48<eskil>and you want streaming because nfs blows, and I wanted to know which kind of streaming you were looking for.
14:49[~]eskil begins to wonder if adding a ice/shoutcast server to myth would be cool...
14:49<gbee>I'm liking upnp at the moment, mostly as a way to avoid additional setup/config for accessing of files at the time of playback
14:50<gbee>I want streaming, not because NFS blows but because it requires the end-user to know how to setup NFS, to create new mount rules etc all of which is a pain in the arse if you just want things to work 'out of the box'
14:51<xris>esp. when the current mythmusic requires mountpoints, etc. to match between machines
14:51<gbee>I don't know what type of streaming I want yet - but as CDev_ has already implemented a getMusic method, I was just planning to experiment with it
14:52<gbee>I've got no further than the theory of it at the moment - If it works well, then at the very least it can serve as an interim method until something better is written
14:53<xris>well, it's just http streaming, which is cool.
14:53|-|onixian [] has quit [Read error: 104 (Connection reset by peer)]
14:53|-|onixian [] has joined #mythtv
14:53<xris>could always add transcoding later on... convert everything to mp3, etc., if we wanted to turn things into a real streaming server
14:55<gbee>I'm using 'getMusic' because it's there - if it wasn't I probably wouldn't even be talking about having mythmusic streaming just yet ;)
14:56<xris>I'll switch mythweb to it as soon as there's a getMusicArtwork method. :)
14:56<gbee>a true uPnP/Ipod client would be great, but I don't want to write it, not now at least
14:56<gbee>xris: hint taken, going to work now
14:57<eskil>gbee, I want to, am quite a way there, but man it takes time, and man it's hard to keep all the patches up to date...
14:57<xris>I didn't even mean it that way
14:57|-|xris [] has quit [""]
14:58<gbee>xris: I was joking really, I've already got the editor open to start I just got sidetracked by IRC ;)
14:59<gbee>eskil: are you replacing the current method of accessing files and metadata storage, or just extending them with alternatives?
14:59<eskil>gbee, extending/rearranging.
14:59|-|xris [] has joined #mythtv
15:00<gbee>eskil: in which case maybe we can start merging some of it
15:00<eskil>gbee, kinda moving a lot of it into the whole storage concept, where the existing db is the default ever-present storage.
15:00<eskil>gbee, once I have something that's stable and worth using, I'd love it.
15:00<gbee>eskil: great, that sounds good
15:00<eskil>gbee, but it's near impossible to separate into smaller patches, just be warned.
15:06<gbee>eskil: btw, as you use the albumart visualizer and I don't - I'm planning on looking for albumart during scanning and adding it to the DB at that point
15:06<gbee>would that cause you any problems?
15:08<eskil>Nope, but you could end up duplicating a fairly big amount of data. Would you try and compare images to make sure that 24 tracks with 200k jpg don't cause 24*200k of database data ?
15:08<eskil>I know that ie. the ipod bozos didn't put the album art in the db partly for this reason, but then again, that's a more constrained device.
15:09<gbee>ah, not storing the images in the database - just the path and the directory id
15:10<eskil>ah, aces.
15:10<gbee>schema for the table would be: albumartid, path, directoryid
15:10<gbee>nice and simple but it would allow things such as mythmusic access to the information
15:10<eskil>but that wouldn't work for images that are id3v2 tags ?
15:11<gbee>mythweb rather
15:11<eskil>that'd be neat.
15:12<gbee>eskil: no it wouldn't, which is problematic if all your artwork is stored that way
15:12<gbee>I mean mythmusic would be able to access it still, but mythweb obviously wouldn't
15:12<eskil>well, win some, lose some.
15:13<eskil>One could always write a small tool to populate the directory and db from the id3v2 tags.
15:14<gbee>the image could be extracted from the id3v2 tag during scanning and written to the directory - a fourth field in the database for songid could allow images to be linked against an individual song rather than every song in the database
15:15<gbee>every song in the directory
15:18<eskil>Sounds good.
15:18<eskil>And this could be extended to have artist art as well.
15:19<eskil>(just for the fuck of it)
15:19<gbee>why not ;)
15:25<eskil>it would make perfect sense.
15:30|-|melunko [n=hmelo@] has joined #mythtv
15:33|-|adante_ [] has joined #mythtv
15:42<gbee>eskil: have you tested those playbackbox changes? works as expected here, but I wasn't having a problem before anyway
15:44<eskil>I've tried out pretty much just that, except I didn't move the reset down to after the pause.
15:44<eskil>I can try out that patch, but not till later tonight (PST).
15:45<gbee>ok, should be safe to commit then
15:45|-|mccune [] has quit []
15:48|-|adante [] has quit [Read error: 110 (Connection timed out)]
15:48|-|adante_ changed nick to adante
15:49|-|onixian [] has quit [Read error: 110 (Connection timed out)]
15:54[~]gbee scans a couple of album covers to test with
15:55|-|cheeseboy16958 [] has joined #mythtv
15:56|-|cheeseboy16958 [] has left #mythtv []
15:56[~]gbee first removes the mountain of paperwork burying the scanner
16:04[~]briand sighs.
16:05<briand>if only we could also access that music data sorted (properly!) by artist name...
16:08<eskil>briand, referring to ticket#2592 ?
16:12<briand>i dunno, i don't remember the number now.. :)
16:12<briand>but i submitted a patch to add a artist_sortkey column to mythconverg.music_artists
16:13<briand>with the corresponding edit controls in the various -ui.xml files, to change/save the value from the [i]nfo screen
16:14<briand>i don't think it'll apply cleanly now.. i'll have to go through it -- there've been some changes to several of the files over the past couple weeks
16:17<briand>eskil: #3104
16:19<briand>although, after the column is implemented, it should close 2592 as well
16:20<eskil>good, for my fix for that was crap.
16:21<briand>i haven't looked at your patch there... what did you do?
16:22<briand>in mine, I just added the column and a means to edit it (and code in dbcheck.cpp to auto-populate, and code in filescanner.cpp to populate it on import)
16:22<briand>nothing there to actually -use- the field. if yours did (or could do) that, maybe we should combine the two and submit the patch :)
16:24|-|tomimo [] has quit ["Gotta get going ..."]
16:28<briand>coolness! looks like my MythTV box LCD panel should be here by Thurs afternoon. :)
16:28<briand>the HDHomeRun shouldn't be too far behind it.
16:29<gbee>briand: what size?
16:29<briand>only 16x2 lines
16:29<briand>to fit in my nMEDIAPC HT-200BA
16:30<briand>I -really- wanted to find a VFD for it, as it would better match the rest of my components, but alas... none to be found that would mount in there. :(
16:31<briand>nMEDIAPC has a VFD module for their HT-280 box, which is a 2x20 unit.. but it's physically to big to fit in the space allotted in my 200BA.
16:31<gbee>what colour scheme?
16:31<briand>black text, yellow backlight.
16:32<eskil>briand, oh, it's different things. Mine was for a case where the tracks didn't have a tracknumber tag, so they all have zero, and therefore got listed in an odd order.
16:32<briand>cool blue flourescent on nothingness would been a 1d20/+200 on the coolness factor.
16:33<gbee>bought a blue/white one, it's fine but after a while I kinda got bored with that shade of blue
16:34<briand>the board that fits in this box is the 632 series from CrystalFontz .. I saw the blue/white in other series' boards, but not in 632
16:35<gbee>something like this one:
16:35<briand>but it _does_ have a motherboard USB connector cable, so I can plug it into one of 7 (yes, SEVEN) available 2xUSB headers on the motherboard
16:36|-|kurre2_ [] has quit [Read error: 145 (Connection timed out)]
16:36<briand>20x4 would probably be too big for the box, too. :/
16:37<briand>gbee: this is the one I ordered:
16:38<gbee>I once saw a white on black which looked fantastic, but I haven't seen it since and I now wonder if it was ever actually sold, or just a prototype
16:39<briand>check out what I wanted!! :
16:39<briand>*that* would've been totally kick-ass
16:40|-|MoRpHeUz [n=morphbr@] has joined #mythtv
16:40<gbee>aye, LCDs look fine until you compare them against VFD - epecially when it comes to readability at a distance
16:41<briand>exactly. and my home theater tuner/amp and all the components all have VFD displays
16:42|-|knowledgejunkie [n=knowledg@unaffiliated/knowledgejunkie] has quit [Read error: 104 (Connection reset by peer)]
16:44|-|knowledgejunkie [n=knowledg@unaffiliated/knowledgejunkie] has joined #mythtv
16:45|-|melunko [n=hmelo@] has quit [Read error: 110 (Connection timed out)]
16:46|-|melunko [n=hmelo@] has joined #mythtv
16:57|-|tomimo [] has joined #mythtv
17:00|-|l-case [] has quit [Remote closed the connection]
17:00|-|jgarvey [] has quit ["Leaving"]
17:03|-|Cardoe [n=cardoe@gentoo/developer/Cardoe] has quit ["Leaving"]
17:03|-|kurre2 [] has joined #mythtv
17:06|-|MoRpHeUz [n=morphbr@] has quit [Read error: 110 (Connection timed out)]
17:07|-|malban_ [] has joined #mythtv
17:08|-|malban__ [] has joined #mythtv
17:14|-|malban___ [] has joined #mythtv
17:16|-|mchang [] has joined #mythtv
17:16<xris>yes, they exist
17:17|-|pm_ [] has joined #mythtv
17:17<gbee>hmm, why is visual.h in mythtv/libs/libmyth/ ?
17:17<pm_>any nuvexport export?
17:17|-|alieas [] has joined #mythtv
17:18|-|malban____ [] has joined #mythtv
17:18<xris>pm_: I'm probably as close as you can get
17:18|-|alieas [] has left #mythtv []
17:18<pm_>I am having having a hard time running nuvexport as a user job
17:19<xris>wrong channel
17:19<xris>but I'll help what I can in -users
17:19<mchang>xris: sorry - focus shift!
17:25|-|malban___ [] has quit [Read error: 60 (Operation timed out)]
17:26|-|malban [] has quit [Read error: 110 (Connection timed out)]
17:28|-|nn [] has joined #mythtv
17:28|-|nn [] has left #mythtv []
17:30|-|malban_ [] has quit [Read error: 110 (Connection timed out)]
17:32|-|malban__ [] has quit [Read error: 110 (Connection timed out)]
17:35|-|onixian [] has joined #mythtv
17:41|-|malban_____ [] has joined #mythtv
17:41|-|malban_____ changed nick to malban
17:44|-|aevil^aw [] has joined #mythtv
17:45|-|aevil [] has quit [Read error: 110 (Connection timed out)]
17:52|-|malban [] has quit [Read error: 60 (Operation timed out)]
17:57|-|melunko [n=hmelo@] has quit [Read error: 110 (Connection timed out)]
17:58|-|malban____ [] has quit [Read error: 110 (Connection timed out)]
17:58|-|jebel_ [] has quit [Read error: 110 (Connection timed out)]
17:59|-|onixian [] has quit [Read error: 60 (Operation timed out)]
18:02|-|mchang [] has left #mythtv []
18:02<xris>Chutt: thoughts on SoC?
18:02<Chutt>xris, hey, i don't think that just one project (I wouldn't think Daniel's could be done by a student) is enough reason to sign up
18:02<xris>are two projects worth it to you?
18:03<xris>yeah, if it's just me, there's not much to do about it.
18:03<xris>I do know that they had students researching video codecs, etc. last year for the bbc, but the gputrans stuff isn't exactly easy
18:03<xris>nor is it really a "project" to just try to get things working.
18:04<Chutt>yeah, they had some stuff for ffmpeg, too, but they pretty much had students in mind already
18:04<Chutt>so, sorry :(
18:05<xris>oh well
18:06<xris>I'll post on the admins list on my own to see if it'd be worth me doing this on my own, just in case.
18:06<Chutt>deadline to signup is today
18:07<xris>ah, thought it was wed.
18:07<xris>either way...
18:08<Chutt>i don't believe you can automatically give up ownership rights
18:08<Chutt>to code, with a blanket statement like that =)
18:09<Chutt>and we can't ever change license, anyway. too much outside code
18:11|-|Netsplit <-> quits: Cougar
18:11|-|Netsplit over, joins: Cougar
18:11<xris>if we made sure all code went through trac, it's easy enough to put a disclaimer there.
18:11<Chutt>a disclaimer's not enough, i don't think.
18:12<xris>the "by submitting this patch, you agree to..." part of it should be.
18:12<Chutt>i mean, there's probably a reason the FSF requires a signature for signing over ownership :p
18:12<xris>well, it'd be as binding as any EULA type thing.. which is "not very" but people seem to think it's enough
18:16<gbee>should a member variable pointer be prefixed with m_ or as it is a pointer 'p' (which is used in a few places but not mentioned in the coding standards)?
18:16<gbee>or even both? m_p
18:16<Chutt>however you want, really
18:16<Chutt>i'd use m_p, but..
18:17|-|melunko [n=hmelo@] has joined #mythtv
18:17<gbee>heh, thought consistency would be good
18:18|-|beavis [] has quit ["Verlassend"]
18:19<gbee>I've got to say, that from a readability pov using m_ really helps, m_p can't hurt but given the generally limited number of member variables, I can usually remember which ones are pointers
18:23|-|pm_ [] has left #mythtv []
18:28<gbee># pm_ has left the chat. < no, m_p *sigh*
18:28<kormoc>xris, actually, back in 96, the 7th circuit court of appeals ruled the EULA's were legally binding, and set precedence which has been used a few other times
18:29<xris>kormoc: I believe there's also precedence in the other direction, too
18:34<kormoc>xris, as far as I know, no, EULA's were always legally fine, now shrink wrap licenses where you agree to it by opening the box were not.
18:36<xris>I remember hearing about something recently that they were a problem because 99% of people didn't read them
18:37<xris>and some court took that as a concern
18:37<xris>but maybe it was just a theoretical thing.
18:37<kormoc>yeah, as so many people say, ignorance is no excuse
18:38<xris>either way, turning the "submit patch" button into an "submit patch, and I agree..." button would be better than just a disclaimer somewhere
18:38<gbee>xris: can't commit the getAlbumArt http stuff until CDev_ has committed his changes, but aside from that I should be done with this tomorrow
18:38<gbee>I'm off to bed now
18:38<xris>gbee: woot
18:38<janneg>EULAs are void in germany. assigment of copyrights is a different issue but I doubt it would work
18:38<GreyFoxx>Bah, figured out my offby one hour issue in mythweb. I had to restart mysqld so mysql could pickup the change :)
18:39<kormoc>haha, oops
18:39<GreyFoxx>I had restarted apache, but never thought to restart mysqld :)
18:39<kormoc>it's gonna be fun next year if they go back to the old daylight savings again...
18:40<GreyFoxx>yeah,...... all this crap all over again heh
18:49|-|melunko [n=hmelo@] has quit [Read error: 110 (Connection timed out)]
18:53<GreyFoxx>That mythweb commit adding the jobqueue stuff to the recoridng details page isn't mysql 4.0 or earlier compatible
18:53<GreyFoxx>SUBSTR was added in 4.1.x and is just another word for SUBSTRING
19:00|-|daMaestro [n=jon@fedora/damaestro] has joined #mythtv
19:04|-|robthebob [] has quit [Read error: 60 (Operation timed out)]
19:16<xris>GreyFoxx: yeah, someone submitted a bug report about it
19:16<GreyFoxx>ahh ok
19:17<GreyFoxx>I commited the change
19:18<xris>ah, good enough
19:18<xris>feel free to close the bug, then. :)
19:22<GreyFoxx>will do :)
19:27|-|kormoc [] has left #mythtv ["Leaving"]
19:31|-|aevil^aw [] has quit [Remote closed the connection]
19:33|-|MegaByte [n=x1@] has joined #mythtv
19:34<MegaByte>how good is mythtv when it comes to radio streaming?
19:34<MegaByte>Can it load streams dynamically like itunes?
19:42<xris>MegaByte: you won't find an answer in the wrong channel
19:42<MegaByte>xris: Excuse me?
19:43<xris>it's generally a good idea to read a channel's topic before speaking
19:43<MegaByte>xris: Oh, sorry.
19:51|-|kormoc [] has joined #mythtv
19:54|-|kormoc_ [] has joined #mythtv
20:01|-|kormoc [] has quit [Read error: 145 (Connection timed out)]
20:01|-|kormoc_ changed nick to kormoc
20:07<MegaByte>mythtv has no depencency hell?
20:44|-|adante [] has quit [Read error: 110 (Connection timed out)]
20:50|-|kali67 [] has quit []
21:14|-|infinity1 [i=foobar@] has joined #mythtv
21:15<infinity1>any ideas why mythwelcome doesn't restart after exiting mythfrontend?
21:17|-|infinity1 [i=foobar@] has left #mythtv []
21:24|-|mchang [] has joined #mythtv
21:24|-|xris [] has quit [""]
21:24|-|JohnnyST [] has quit [Read error: 60 (Operation timed out)]
21:26|-|kormoc [] has quit ["Leaving"]
21:40|-|mchang [] has quit []
21:50|-|kormoc [] has joined #mythtv
22:14|-|mikal [] has joined #mythtv
22:16<CDev_>Well, it's done. UPnP changes commited!
22:32|-|xris [] has joined #mythtv
22:55|-|jpe-nyc [] has joined #mythtv
22:56|-|jpe-nyc [] has left #mythtv ["Leaving"]
23:01|-|DrNickRiviera [] has quit ["Leaving."]
23:06|-|CyberKnet [] has joined #mythtv
23:29|-|jakeisawake [] has joined #mythtv
23:43|-|waldo [] has left #mythtv []
23:51|-|CyberKnet [] has left #mythtv []
23:58|-|Nem^ [] has quit [Read error: 110 (Connection timed out)]
23:59|-|Nem^ [] has joined #mythtv
---Logclosed Tue Mar 13 00:00:13 2007