Re: [Banshee-List] video patch database model

["Andres G. Aragoneses" <knocte gmail com>]

Hey Olivier, I'm wondering if this work can be split-ed in 2 patches so 
it is easier to review? The first one would be just separating video 
support into its extension, and the 2nd would be adding all 
TVshow/episode/etc functionality you mention. Does that make sense?

On 02/05/2012 02:01 PM, olivier dufour wrote:
> Hi,
>
> I update the video branch to last git and start to work on it again.
> So I will used only one table because It is quite the same data between
> episode/season/tvShow/movie.
>
> Anyway, here are new enhancement of the sytem I plan to do:
> videoinfo will contain metadata (summary, actors, studio, country,
> language,...)
> videoinfoId will be linked to track with
> AlbumID <= VideoId for season
> ArtistID <= VideoId for tvshow or movie
> ExternalID <= videoid for episode/movie
> AlbumMusicBrainzIdField can been use for imdb id of season
> MusicBrainzId = imdb id of movie or episode
> ArtistMusicBrainzIdField = imdbid of tvshow
> tracknumber = episode
> trackcount = total number of episode of season
> discnumber = season
> discount = max season (or not because it evolve)
> playcount will be useful to know if episode is watch or not
> ArtistField = name of the tv-show else movie name
>
> with this I remove parent id but have to manage a type flag in video info
> Else I can do a single table for each (seasoninfo, tvshowinfo,
> episodeinfo, movie info)
> but it will be mainly the same field just gain type and small table for
> processing
> but we have les audio than video... because file take more size on hard
> drive.
>
> Track will be used for more things than previously. We just have to pick
> some music field and used it differently with video. So that will be
> crap because artist for tvshow will mean tv show and album will mean
> season and we will have to rename column on video view but it is easyer
> than doing a video track info wich will replace the databasetrack info
> which is used for audio.
>
> so remaining issue come for episode and movie because the link is
> hard to manage and have no field for it else than externalid. Not sure
> that as ok...
> issue with video on mobile device because external id will be overrided
> by apple id or mtp id. Can someone confirm that will be the case or not?
> solution : add trackid in videoinfo only used for episode/movie.
>
> As usual fosdem was productive ;)
> I will work on my branch to do so and will provide new patch with this.
>
> cheers,
>
> Olivier Dufour
>
>
> On Sun, Jan 29, 2012 at 4:16 PM,
> gnomeuser gmail com
> <mailto:gnomeuser gmail com>
> <gnomeuser gmail com
> <mailto:gnomeuser gmail com>>
> wrote:
>
>     2012/1/25 olivier dufour <olivier duff gmail com
>     <mailto:olivier duff gmail com>>:
>      > Hi,
>      >
>      > Long time I have not work on video patch but I want to work on it
>     again and
>      > first thing to do before review is to know if the database model
>     is the
>      > right one to use.
>      >
>      > So this message is moslty for maintainer/advanced developper to
>     get advice
>      > and know if my database model is right.
>      > I extend the track info by doing my own video table
>      > with [CoreTracks.ExternalID = Videos.VideoID] to link it.
>      > 1) Do you think that I must get back some data by using some free
>     field in
>      > coreTrack not used in video.
>      > 2) Does Using the coreTrack.ExternalId to extend the track with
>     an external
>      > record the right way or you prefer that I let it free and just
>     store in
>      > Video.videoId the coretrack.TrackID ?
>      > 3) to avoid to do an season table and a tv show table I reuse the
>     video
>      > table and link episode - season - tv show with parentId. I do
>     that because
>      > season/tv show need quite same data than an episode. I use video
>     type to
>      > know type (episode, season, tv show, movie) Is it ok or do you
>     prefer that I
>      > add a episodeId and seasonId field and make 2 other tables
>     (season and tv
>      > show) ?
>
>     Not at all an expert but it seems more correct to me to have separate
>     tables for season and episode. I fear that it might make the code
>     harder to figure out if you have to figure out if an episodeid or a
>     seasonid is being extracted at a given point.
>
>     I don't know how SeriesFinale (an application for the N900) does this
>     but it can give me the air date for upcoming episodes as well as
>     indication if a series is cancelled. I'd love to have something
>     similar in Banshee.
>
>     Regardless, I am happy to hear that you are back on the Video patch.
>
>     - David
>
>      > here is the current tables format:
>      >
>      > * Video *
>      >
>      > int VideoID
>      > string imdb_id
>      > DateTime release_date
>      > string language
>      > string title
>      > string original_title
>      > string alternative_title
>      > string info_url
>      > string homepage_url
>      > string trailer_url
>      > string summary
>      > string studios
>      > string country
>      > int parentid
>      > string external_video_id
>      > int video_type
>      >
>      > * CastingMember *
>      >
>      > int CastingMemberID
>      > int VideoID
>      > string Name
>      > string Character
>      > string Job //director, actor, author, special guest...
>      >
>      > cheers,
>      > Olivier Dufour
>      >
>      > _______________________________________________
>      > banshee-list mailing list
>      > banshee-list gnome org
>     <mailto:banshee-list gnome org>
>      > http://mail.gnome.org/mailman/listinfo/banshee-list  (unsubscribe
>     here)
>     _______________________________________________
>     banshee-list mailing list
>     banshee-list gnome org
>     <mailto:banshee-list gnome org>
>     http://mail.gnome.org/mailman/listinfo/banshee-list  (unsubscribe here)