On 11/24/14, vedant agarwala <vedant.k...@gmail.com> wrote: > On Mon, Nov 24, 2014 at 5:56 PM, Nitul Datt <nitul1...@gmail.com> wrote: > >> On 11/24/14, vedant agarwala <vedant.k...@gmail.com> wrote: >> > Hello Nitul, >> > >> > I am not thoroughly familiar with the code but here is my suggestion: >> > >> > The CollectionScanner should find files and represent them. So if it >> finds >> > a track it represents it as such. You should have a one Track object >> > representing a track and a new CueSheet (or similar) class object to >> > represent a cue sheet. >> > >> >> Won't that make two entries for the same file, ie one for the music >> file and one for the corresponding cue sheet, since the music file >> will be scanned as such and the cue sheet as well? The solution to >> this seems to be that we only store the cue sheet file and not the >> corresponding track. This seems like a better approach than what I was >> trying earlier. What do you think? >> > > I thought that a cue sheet is a separate file. Anyway, you are right: only > one object should represent one file. So we should have just a CueSheet > file. > > >> >> > But when these files are shown in the Database collection/playlist etc. >> in >> > amarok they should be shown as completely different (according to the >> music >> > file and cue sheet) files (i.e. different TrackPtr 's should be created >> for >> > each). >> > >> >> Yes, that may be achieved using timecode tracks. I haven't been able >> to find how timecode tracks are represented in the database though. >> >> > The thing that I haven't figured out is that how will amarok "dissect" >> > the CollectionScanner::Track >> > if it is a cue-sheeted track. Can you place some link in the >> > CollectionScanner::Track >> > to the corresponding CollectionScanner::CueSheet without modifying it? >> > Or >> > when the CollectionScanner::CueSheet is accessed by Amarok, it should >> > dissect the CollectionScanner::Track into many TrackPtr 's. >> > >> >> I'll look into it. >> >> > It really depends on how the information fed by the collection scanner >> > to >> > amarok is parsed by amarok. Look into and figure it out. >> > >> > Ask me again if needed. >> > >> > And, always 'cc' amarok-devel. Maybe someone would help you. Even if >> > they >> > don't, they will be glad to know how the amarok community is bonding >> > and >> > growing. >> > >> > Regards, >> > Vedant. >> > >> > On Sun, Nov 23, 2014 at 10:41 PM, Nitul Datt <nitul1...@gmail.com> >> wrote: >> > >> >> Hey! >> >> >> >> I've run into a bit of a roadblock and require your guidance. How >> >> should I represent the individual tracks in a cue sheeted file? At >> >> present, the collection scanner does not include start and end times >> >> for regular tracks. The existing cue sheet related code creates >> >> timecode tracks for the individual songs in a cue sheeted file. That >> >> being said, should I thus create a new CollectionScanner::TimcodeTrack >> >> class or make changes to the existing CollectionScanner::Track class? >> >> >> >> -- >> >> Regards, >> >> Nitul Datt >> >> >> > >> >> -- >> Regards, >> Nitul Datt >> > > Try and keep things on schedule. You wasted quite some time initially > "going through code".
Wasn't quite sure how to proceed. > I still don't have any reviewable code. > Will do. > Regards, > Vedant. > -- Regards, Nitul Datt _______________________________________________ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
