Re: [Banshee-List] video patch database model



Hi,

Yep and it is alaready done.

Here is the patch to just make video as an extention.
https://bugzilla.gnome.org/show_bug.cgi?id=536656
David test it and it work pretty well.
But I need a review.

Olivier Dufour


On Sun, Feb 5, 2012 at 8:21 PM, Andres G. Aragoneses <knocte gmail com> wrote:

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)






_______________________________________________
banshee-list mailing list
banshee-list gnome org
http://mail.gnome.org/mailman/listinfo/banshee-list  (unsubscribe here)



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]