[00:01] <tgm4883> I don't know if it has comm skipping, but you could look at linvdr
[00:01] <tgm4883> it has some plugin called noad
[00:03] <h2os> http://www.linuxtv.org/vdrwiki/index.php/Noad
[00:03] <h2os> might be what i want
[00:05] <tgm4883> yep, then you just need a program that will read the cutlist
[03:07] <omoore> hello all.. anyone awake? :) I am thinking about filing a bug that I don't see listed.. but want to ping you guys to see if anyone knows about this issue...
[03:07] <rhpot1991> omoore: whats the issue?
[03:07] <omoore> I am seeing non-date information in date fields of both Recorded and RecordedProgram tables...
[03:07] <omoore> the issue seems to be...
[03:08] <omoore> that when a description has special characters, the SQL is probably not escaping the content properly...
[03:09] <rhpot1991> omoore: interesting, you should make a bug and include information about where your data comes from
[03:09] <omoore> frankly.. I am surprised it *could* get in there.. anyway.. when i use a database tool to query the data...
[03:10] <omoore> (considering the datatype for the column)
[03:10] <rhpot1991> what do you use for your listings?
[03:11] <omoore> the listings look fine.. it's when i query the database table.. specifically.. i'm using JPA, but it also shows odly when querying via JDBC.. and the MySQL query tool
[03:11] <omoore> ie.. mythweb lists ok.. as does the mythtv client...
[03:11] <omoore> but if i query the data directly.. some date columns have invalid data...
[03:11] <omoore> (using JDBC, JPA or the MySQL query tool)
[03:13] <omoore> I also was going to try a fresh install first.. since I want to rule out some oddity with my installation.. because I have also noticed that a station which changed channels in my area still shows as the old station
[03:13] <omoore> (too bad! it's SCIFI! :) )
[03:14] <rhpot1991> omoore: well the thing to do would be to see if thats bad data you are getting from somewhere or what the deal is
[03:14] <omoore> The database is pretty small.. you think there would be value in my dumping the db and having it available to the person working the bug?
[03:14] <rhpot1991> if its being cleaned up by something on myth's end then it may not be an issue
[03:14] <omoore> no external updates are being done.. unless mythweb is messing something up...
[03:15] <omoore> which might be thecase as i work almost exclusively with my mythbacken from a mythweb browser widow
[03:15] <rhpot1991> omoore: mythweb could be cleaning that up before showing it to you or something
[03:15] <omoore> window
[03:15] <omoore> ahh.. right
[03:15] <rhpot1991> omoore: you could just do a dump of the problem rows, tar.gz that up and attach it to the bug
[03:16] <omoore> true.. should be small enough...
[03:19] <rhpot1991> omoore: so what you do is mysqldump -u<user> -p mythconverg <tables tables> --where="something='something'" --no-create-db --no-create-info > dump.sql
[03:19] <rhpot1991> keys on the recordings tables are normally chanid and starttime
[03:19] <rhpot1991> then if someone so wanted they could import that
[03:21] <omoore> will do.. i think i will dump the database and preserve.. but going to rbuild too just to be sure it isn't something screwey with my environment (i copy off the recordings to a network attached storage box here at home so no data to speakof on the actuall myth box)
=== anii is now known as aniiena
[16:17] <lifewithryan> anyone running mythbuntu with a pvr350?  i'm getting scrambled recordings over basic cable...
[16:32] <c0p3rn1c>  I just removed the package ubuntu-mythtv-frontend but the mythtv user account still tries to login, how do I stop this?
[16:33] <tgm4883> c0p3rn1c, have you looked in System > Administration > Login Window
[16:33] <tgm4883> under the security tab
[16:33] <c0p3rn1c> I'll check thx
[16:35] <c0p3rn1c> tgm4883: should I also delete the account ?
[16:42] <tgm4883> if you want?
[23:48] <tmetro1> After synchronizing versions between an 8.10 front-end and 8.04 back-end by running the 0.21.0+fixes19878 weekly build on both, I'm still seeing the front-end fail to start with a complaint:
[23:48] <tmetro1>  Unexpected DB Schema version. ... QString::arg(): Argument missing: ERROR: Unable to acquire database upgrade lock ... Access denied for user...
[23:48] <tmetro1> I don't get why it is still (saw this before I synced up versions and though it was version skew) trying to upgrade the schema. I've restarted the back-end process and ran a front-end there locally, which should have triggered any needed schema upgrade.
[23:50] <tmetro1> The db user has more limited access rights than the typical mythtv MySQL user. Is this error a red herring and it just needs sufficient access to create a temporary table for a lock semaphore and then it'll be happy?