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