Log from #neuros IRC channel

crweb: we talked about that with Joe the other day. but 1) neuros needs to ship a bundled card, we can't expect them to have it 2) users still need to fumble around with cards or they get no EPG. doesn't seem the easiest thing for end-users

[00:39]

<crweb>

nerochiaro: with all that data though, if you want EPG have external card dedicated to EPG/scheduling doesn't seem to much of a requirement

[00:39]

<crweb>

the device is usable without EPG

[00:40]

<crweb>

another thing to look at is, how are playback of EPG recorded titles going to work?

[00:41]

crweb: well, Joe says EPG is kind of a must to be a tivo replacement. also, we can do the card thing, but i think we still need to have a "degrade gracefully" situation when they want to pull off the card for whatever reason. and in that case we go back to updating only the favorites list, no ?

[00:41]

<crweb>

I'm doing some quick calculations on minimal size

[00:41]

<crweb>

i'll be a sec

[00:41]

crweb: i'm going to add that too to the design, i just didn't have time to add it

[00:41]

yesterday

[00:42]

[g2]: so it's PC based

[00:43]

<[g2]>

nerochiaro, yeah for now

[00:43]

<[g2]>

and probably for a while

[00:43]

<crweb>

ok. Channel[1byte], Episode#[1 byte], ShowTitle[30 bytes], ShowDesciption[200 bytes],AirDate[6bytes],RecordDate[6bytes],RecordTime[6bytes]

[00:44]

<crweb>

Wiat, i forgot what i was doing

[00:44]

<crweb>

thats the wrong list

[00:44]

crweb: that's not really useful anyway, don't bother

[00:44]

<crweb>

nerochiaro: looking at storage size

[00:44]

<[g2]>

nerochiaro, crweb are you guys creating a show / episode index ?

[00:44]

<crweb>

even for a favorate list update

[00:44]

i mean, we don't yet know how much data will the provider give us

[00:45]

<crweb>

nerochiaro: we don't have to use "all" the data

[00:45]

<crweb>

but title, time, date, channel, and desc are a must

[00:45]

[g2]: there will be search by show name (and schedule all episodes of show)

[00:46]

crweb: it's better to use as much as we can, provide the user with rich information

[00:46]

<crweb>

"if" you have the spacfe

[00:46]

crweb: of course

[00:46]

<crweb>

i'm doing minimal count here

[00:46]

ok

[00:46]

<[g2]>

nerochiaro, if the show/episode has an index, then the db is compressed alot as all the other info associated with it only needs to be stored once

[00:47]

<crweb>

right, we can lose some fields in the db by using foriegn keys and stuff

[00:47]

<crweb>

channel names would only have to be stored once, etc

[00:47]

[g2]: good thinking, and speeds up searches. you mean just show name though, episode title doesn't need that

[00:47]

<crweb>

even episode titles can have indexs, title only stored 1 time

[00:47]

channels are already in a separate table in the stuff i did

[00:48]

<[g2]>

well title == epidode

[00:48]

for episode titles there's no point. episode title is stored one time anyway

[00:48]

<[g2]>

and maybe more than 1

[00:48]

<crweb>

nerochiaro: more than one. the title would show up in each "hour"

[00:49]

<crweb>

nerochiaro: each time displayed the title would show. If its not in its own table, you'll have to store the title text over and over

[00:49]

crweb: why so ? if it lasts 2 hours, the title is not stored 2 times. it just takes a 2 hour slot

[00:49]

<crweb>

nerochiaro: you're thinking that it only happens once

[00:49]

<crweb>

but in a 2 week period, it could happen every night for 2 hours

[00:49]

oh, reruns

[00:50]

<[g2]>

right that "Paid Programming" title is used alot at night

[00:50]

<[g2]>

lots of channels repeat like every 3 hours

[00:50]

great, thanks. that's the kind of feedback i wanted :)

[00:50]

<crweb>

nerochiaro: same with descriptions

[00:50]

<crweb>

nerochiaro: the descriptions should be have keys based on title name and episode number

[00:51]

<[g2]>

which is the reason the series/episode can have all the data scrunched into one index

[00:51]

<crweb>

because again, they happen more than once

[00:51]

<crweb>

worst case is that they only happen once

[00:51]

<crweb>

best case if they happen more than once

[00:51]

crweb: once you have the whole programme as a separate entity with an ID, then you can store title+description+info with it and use the key everywhere else

[00:51]

as [g2] said

[00:52]

<crweb>

nerochiaro: mm.. descriptions are different for different episodes though

[00:52]

<[g2]>

nerochiaro, I was thinking of merging the program index and episode numbers

[00:53]

<[g2]>

something like 24bits program number, 12 bits episode

[00:53]

<crweb>

nerochiaro: you pretty much will need a table with a key for almost all the fields

[00:53]

<crweb>

your "main record" would be key/episode number and all the others be foriegn keys to other tables

[00:54]

crweb: the description goes into the same table with the episode title

[00:54]

<crweb>

nerochiaro: no it wouldn't

[00:54]

crweb: sorry, the episode isn't the same on reruns ?

[00:54]

crweb: the content is the same

[00:54]

<crweb>

nerochiaro: it is the same yes

[00:54]

so ?

[00:54]

<crweb>

nerochiaro: but whos to say the descript doesn't change?

[00:55]

<crweb>

nerochiaro: oh wait

[00:55]

[g2]: with an sql database i'm not sure that key merging does help lots

[00:55]

<crweb>

nerochiaro: i was skipping ep title

[00:55]

<crweb>

nerochiaro: ep title to me means show is Named "Scrubbs"

[00:55]

<crweb>

nerochiaro: my bad. Yes desc and ep title would be samet able

[00:56]

<crweb>

Show title would be a seperate table

[00:56]

crweb: "Scrubs" is the show title. EP title would be "a bad day" or something

[00:56]

<crweb>

sorry bout that

[00:56]

crweb: ok

[00:57]

<crweb>

your #1 issue in using sql lite

[00:57]

note to self: publish a draft of database schema

[00:57]

<crweb>

sql lite doesn't do foriegn keys

[00:57]

crweb: what do you mean ?

[00:57]

<crweb>

theres no automatic relation between 2 tables

[00:57]

<crweb>

you have to do it by hand

[00:58]

<[g2]>

I think it depends

[00:58]

<crweb>

sql servers usually provide you the ability to limit a field to a foriegn key

[00:58]

<crweb>

if the foriegn key doesn't exist it errors/ pops up conditions/handles it

[00:58]

<crweb>

sqlite does not support designating foriegn keys

[00:58]

crweb: the big problem with that is on insertion. we don't care, the db will be read only

[00:59]

<crweb>

it hurts with reading too

[00:59]

<crweb>

cause you can't simply just look up a foriegn key, you have to know in your code which table the key refers to

[00:59]

why so ? if you know in which table to lookup the ID you should not have problem

[00:59]

yes, and we do know

[00:59]

<crweb>

right, you have to do it in code

[00:59]

<crweb>

not in sql

[01:00]

<crweb>

way easier to let the sql server do that for you

[01:00]

the query can have sub-queries i think

[01:00]

<crweb>

but you have to know what to sub-query

[01:00]

<crweb>

its just a pain is all

[01:00]

<crweb>

very easy to make mistakes

[01:01]

<crweb>

most of the problems are on insertion though

[01:02]

well, ok. i'll push a db model out of the door later today or tomorrow you folks can poke at

[01:02]

any other holes or stuff you want to comment in that design on wiki ?

[01:03]

<crweb>

with rows in the main table using all fields as keys (say 8 basic details) that are say int8 the row sizes alone are 256bytes

[01:04]

<crweb>

it would actually be to hard to calculate db sizes

[01:04]

you don't know how many programmes a day there are for each channel

[01:04]

<[g2]>

nite all

[01:05]

[g2]: nite

[01:05]

<crweb>

you can get a minimal size by adding the sizes of all the rows in the table

[01:05]

<crweb>

all empty

[01:06]

<crweb>

I do know that in my current db, with no keys, with data repeats. mp3 id3 tags for 600 songs is 300k

[01:07]

<crweb>

it would be hard to determine the size of EPG data if we take out all the repeating data

[01:07]

<crweb>

would just have to "do it" and see

[01:08]

<crweb>

i do have an algorithm around here to test the size

[01:08]

<crweb>

but probably should have a final schema before running it

[01:10]

crweb: i'll try to put out some schema after i see to this IR stuff

[01:10]

<crweb>

www.mythtv.org

[01:11]

<crweb>

mythtv isn't very worried about db space

[01:12]

indeed they are not

[01:12]

<crweb>

we can do much better. but that is pretty much all the data

[01:12]

<crweb>

they have a lot of epg providers they have written that for

[01:13]

also i wonder if we really need endtime at all

[01:13]

<crweb>

you have to beable to tell the recorder when to stop

[01:13]

it stops when the next program begins

[01:13]

<crweb>

says who?

[01:14]

<crweb>

what if a user needs it to be +-1 minute

[01:14]

<crweb>

or +-5 minutes cause their provider lags

[01:14]

he manually overrides. but the programme end there, doesn't end +/-1 minute.

[01:14]

<crweb>

you have to tell it +- from the "end time"

[01:15]

yes,and the end time is calculated as being equal to start time of next programme. that's avoiding a lot of duplicate information

[01:15]

<crweb>

but again, thats not nessicarily the start time of the next program, it might be +- also

[01:16]

really ? so there are "holes" among programmes ?

[01:16]

where the screen shows static ?

[01:16]

<crweb>

there is if you stop your recording 1 minute early and start the next one 1 minut late

[01:17]

but that's not in the EPG database. that's what you do manually on your own

[01:18]

hi all

[01:18]

hey JoeBorn

[01:18]

<crweb>

i'm pretty sure its there for a reason

[01:19]

<crweb>

to look up what time to stop recording, you have to look at the next program

[01:19]

<crweb>

but the next program on what channel?

[01:19]

crweb: on the same of the recording

[01:20]

<crweb>

so you'll have to do 2 lookups

[01:21]

<crweb>

you can't just say "find the next program"

[01:21]

<crweb>

that way

[01:21]

<crweb>

you don't have an end time, so where do you look to get the next program

[01:21]

crweb: not necessarily. when you schedule a recording, you do the lookup and store the end time by looking at the next program. but you do this once, at schedule time. and you save the end time on all records

[01:21]

save in the sense of "you don't have to store it"

[01:22]

"save space for"

[01:22]

<crweb>

i think it would be harder to find the next program, than space saved

[01:22]

crweb: where do i look for the next program ? i look at the first program with a start time higher of the current program, on the same channel

[01:23]

<crweb>

theres lots of times that are higher

[01:23]

<crweb>

hmm..

[01:23]

<crweb>

sorry, I'm just trying to defend myth tv. we can move on

[01:23]

but only 1 that comes after

[01:23]

ok

[01:23]

:)

[01:24]

i'm not sure it's the best way

[01:24]

we need to try and see

[01:24]

<crweb>

i know we don't want to do length

[01:24]

the way i designed it, it won't actually matter, as we have a data model api that abstracts the DB stuff away

[01:24]

and yes, i tried len and it's a pain

[01:25]

<crweb>

are we going to try and store the program data for things that are already recorded?

[01:25]

<crweb>

files don't have that sort of meta data, so if data isn't in the file name, then its gone

[01:26]

yes, it will be moved to a separate table, but basically be a copy of the original EPG data

[01:26]

or even the same table with a marker

[01:26]

<crweb>

and when the person removes the medium that was recorded to?

[01:27]

crweb: if we go the "make a copy" route, it can reside in flash. i don't thing people will make hundreds of recordings

so it can stay small

ah

sorry

you mean the actual file

[01:27]

<crweb>

i actually just had an idea

[01:28]

<crweb>

instead of putting playback data back into a db

[01:28]

<crweb>

lets make a metadata file and store it "with" the recording

[01:28]

<crweb>

users can then make their own metadata content

[01:28]

into the recording or with it ?

[01:28]

<crweb>

and copied video's can have metadata too

[01:29]

<crweb>

videoname1.avi, videoname1.txt

[01:29]

<crweb>

videoname1.avi, videoname1.nmd neruos metadata

[01:29]

<crweb>

we'd not have to worry

[01:29]

crweb: i honestly hate that kind of pollution. either metadata resides in file or it's guaranteed to get lost

[01:30]

<crweb>

well, if you store it in the db, the file gets lost

[01:30]

<crweb>

the only way you're going to put it in the file, is nupple video

[01:32]

if you keep it with the file, how does it get less "lost" ?

[01:32]

<crweb>

it doesn't get less lost. but if the media is removed, you didn't have to store it. When its plugged back in, its back, you don't have to search for it

[01:33]

<crweb>

if its gone, the person must not have wanted it

[01:33]

<crweb>

add a checkbox, save metadata or not

[01:34]

<crweb>

everyone else created their own file formats to store the metadata

[01:34]

<crweb>

we are stuck using industry standard formats

[01:35]

there's a metadata thread on the ML, you all may recall.

[01:35]

JoeBorn: actually i'm not sure i've seen it

[01:35]

which seemed to suggest that in fact there is no single standard as mr. web suggested

[01:36]

<crweb>

i just met the girls that live down stairs

[01:37]

groups.google.com

[01:37]

crweb: congratulations!

[01:37]

crweb: go have fun man ! ;)

[01:37]

<crweb>

kinda

[01:37]

* JoeBorn scratches head

[01:37]

<crweb>

a little drunk for my tastes..

[01:37]

<crweb>

and sure to keep me up much past my bedtime

[01:37]

crweb: dont' worry, they'll be sober tomorrow

[01:38]

<crweb>

hah

[01:38]

a little drunk is good. dead drunk is what should get you worried

[01:39]

<crweb>

i was being nice

[01:40]

<crweb>

roommate wants to have a music loudness contest obviously

[01:40]

<crweb>

:D

[01:40]

<crweb>

I always win those

[01:40]

* crweb fires up the studio monitors

[01:40]

nerochiaro: what do you think about that xmms testing ?

[01:41]

should I start obnoxiously complaining about my setup woes on the xmms2 channel?

[01:41]

can I make new friends that way?

[01:41]

it's xmms2 server setup or the clients ?

[01:41]

<crweb>

i haven't had much luck with xmms2 on my pc's even.

[01:42]

<crweb>

is it wrong to call the cops on your own apartment?

[01:43]

JoeBorn: because the server works fine for me. but i'm having problems with some of the clients. but it's not xmms2 channel's fault, although you can ask their help i think

[01:43]

ok.

[01:43]

crweb: I once went on a ride along with my wife one time, you would not believe the stuff people call the cops for

[01:44]

half the time was spent on stuff that shouldn't have made it into small claims court, let alone get the police running around with.

[01:44]

<crweb>

true.. guess i could call the campus police

[01:45]

<crweb>

they like to beable to pretend they are real cops

[01:45]

<crweb>

heh...

[01:45]

<crweb>

eh, maybe i'll just get dressed and join them for a bit

[01:46]

just put on a robe and go down there

[01:46]

that will show them you mean business.

[01:46]

like hugh hefner

[01:52]

I think I'm going to cool it with the milk pearl tea. I think now that I have a few pound of those gummy balls sitting in my stomach the novelty of 12 cent tea has worn off :(

[01:52]

I'm sure they are the kind of thing that takes 7 years to pass through your system completely.

[01:53]

<crweb>

nah, they are just jelly

[01:53]

<crweb>

make from tree roots

[01:53]

<crweb>

they disolve pretty easily

[01:53]

are they fattening?

[01:54]

<crweb>

i don't think you can eat enough of them for them to be fattening

[01:54]

will I need to buy new pants now that I have eaten four pounds of them over the last 48 hours?

[01:54]

oh, well onward ho then!

[01:57]

I'm thinking we should do the xmms2 dbase generation up front kind of like we did for the N1&2 upon sync. what do you all think?

[01:57]

it seems like a kind of natural process rather than the build as you go type thing

[01:59]

well, the problem is more a problem of space than a problem of speed of generating it, i think

[01:59]

and instead of build as you go with can have the OSD generate it at once, you tell it where the media is, and it adds it to the database

[02:51]

BTW, all as a general note, when writing bugs that you expect the china team to execute on, create a simple do 1, 2, 3 list at top and then a "background" section below.

[02:52]

there's a lot of overhead for them reading a big elaborate explanation interwoven into the action items.

[02:54]

good thinking. send that thought to ML plase

[02:55]

ok, let me create a bug that shows it (which I'm doing now)

[03:08]

this is not that bug, but on a separate note bugzilla.neurostechnology.com

[03:09]

sounds fine to me as a note, until we decide what to do about storage

[03:14]

well, I think the rest is just marketing, note language and bundling.

[04:16]

Hello, is there anybody I can talk about GSoC?

[04:16]

sure

[04:17]

Vitaly: we are here for you.

[04:17]

great! yesterday there were nobody to talk to.

[04:18]

i am really interested in two ideas: Torrent client and upnp av suppoprt

[04:18]

i have submitted application for torrent client already. have you seen it?

[04:19]

yes

[04:21]

nerochiaro: can you give my any guidelines what to do next? what project is more important torrent client or upnp av. i can write my upnp support thoughts also.

[04:22]

Vitaly: you can submit for both torrent and upnp av. then we will assign students and assign the ones with better proposals

[04:24]

the applications for students end at 24th March

[04:25]

oh, 26th, they moved it

[04:25]

you wrote about tinyurl service integration on your ideas page. i don't understand the idea. where do these short urls will forward to?

[04:26]

suppose you have a torrent that you want to download, but the url to the torrent file is 600 characters long. it's impossible to enter it with the remote. but if you forward it with a tiny url of only 6 or 8 numeric characters, it's easy to do with the remote

[04:28]

yes it is obvious of course. i thought there lies something different. ok.

[04:31]

ok, thank you. hope to join your community soon.

[04:31]

Vitaly: even if you don't approved for summer of code, you can still join the community of cours

[04:32]

yes sure.

[04:32]

one more question

[04:32]

as i understand there is no samba client in neuros yet?

[04:33]

there is one, to access windows shares

[04:34]

ok

[04:37]

each student is allowed to post 20 applications to different projects. Do you know how it will be determined in which project I will participate if I am accepted by several mentoring organizations?

[04:38]

Vitaly: you will decide it, i think

[04:42]

ok, thank you. good bye.

bye

nerochiaro, ping

pong ?

hi nero =)

im about to fill the gsoc request

[05:01]

what should i put on the abstract?

[05:01]

haven't filled something like that before :)

[05:02]

any clue? or example?

[05:02]

turran: one second

[05:05]

turran: well, i'm telling everyone to be specific as possible in the "detailed description". also include in there a link to a CV if you want. as for the abstract, just condense the more important points of the project and of how you plan to implement it

[05:05]

may1937: you there ?

[05:06]

nerochiaro, ok, "how to implement" the bridge might be a difficult question to answer :)

[05:06]

turran: well, any information you have on research you have done. make you proposal compelling :)

[05:07]

the point it, if you can, be as specific as possible. of course if not possible, it's ok

[05:12]

beaufour: you're from joost?

[05:15]

JoeBorn: yep

[05:15]

oh, didn't know that. Nice to have you.

[05:15]

how are things with Joost?

[05:15]

well, my Neuros activity has not been very high lately

[05:15]

ok, moving forward every day

[05:16]

<Ycros>

I have a joost beta account

[05:16]

I'm looking through my emails, and seeing that I should have known that :(

[05:16]

<Ycros>

cool stuff, I like it, but not much content means I've only used it a few times

[05:17]

my brain has sadly becom flaccid.

[05:17]

Ycros: yeah, we need some more content

[05:17]

but it's on the way :)

[05:17]

JoeBorn: that's ok :) but yeah, 'beaufour' is pretty unique :)

[05:17]

if anybody here needs a beta account feel free to ping me btw

[05:18]

<Ycros>

beaufour: I can understand that you can't get much content without a large userbase or a finished product

[05:18]

Ycros: well that's not necessarily true

[05:18]

<Ycros>

beaufour: but I've watched everything on there that I've found interesting :P

[05:18]

* beaufour mumbles something about Viacom :)

[05:18]

<Ycros>

JoeBorn: my guess is that content is quite expensive

[05:19]

I think joost is probably pretty reasonably capitalized

[05:19]

* beaufour cannot talk about content deals

[05:19]

and they have a lot of momentum, and hollywood is looking to get into the game, look at the deals they've made with BT

[05:19]

<Ycros>

aye

[05:20]

I expect Joost will do fine, I wish we had more time and resources to work on an integration.

[05:20]

<Ycros>

I see joost as having great potential, I too thing it's going to do quite well

[05:21]

we shipped some OSDs to them at their request, they were even classy enough to pay for them.

[05:21]

<Ycros>

yeah, running joost on the osd would rock.

[05:21]

something I cannot say for all our potential partners *ahem*

[05:21]

<Ycros>

hehe

[05:24]

heh

[05:25]

1st priority is to get a stable Windows (and Mac) client, then the rest will follow ... but we'll get to stuff like OSD

[05:25]

Well, they did OK with Skype so they must be better off than most . . .

[05:26]

<Ycros>

beaufour: totally sensible since most of your userbase is on windows

[05:26]

at least for now ... our "userbase" is everybody watching TV....

[05:27]

sorry for the ignorance, but joost is streaming tv over internet ?

[05:27]

yes

[05:27]