[campcaster-dev] Re: MCM tech spec, draft 4
  • Vote Up0Vote Down importimport
    Posts: 0Member
    I agree with most of the estimates; below are some comments:

    > Optional:
    > 1f. Add a flag to the scheduler database indicating whether
    > the song has been completed or not. Make the scheduler change this
    > flag when a song is completed. Database upgrade script required.
    > $$$ 2 days (Paul)

    I don't see the reason for this flag; it was a tool for the
    pull-things-forward-in-time resume feature, but we agreed not to do
    that, I think. The log file is enough to determine how many times a
    clip (or ad) has been played.


    > 2c. Add a global config value to set the system-wide cross-fade value.
    > This will be used by the scheduler as the default cross-fade time.
    > $$$ 2 days (Paul)

    Here and elsewhere: what do you mean by "system-wide" configuration
    settings? Do you want to create a config file used by all components?
    It could be very complicated to account for all possibilities, including
    two-computer setups. And it does not seem necessary: the logical place
    for such a config setting would be in the element of the
    two existing config files (Scheduler and Studio).

    Of course, we'd need to provide an XML-RPC API for changing these
    settings, and one or two GUIs using this interface.

    There are two options here, of similar (fairly high) complexity:
    a) create this system-wide config file, and make it work in all
    possible setups;
    b) create the extra functions in the Scheduler mentioned above.

    I estimate either one to be about 5 days, and I think option (b) is much
    better.

    Please imagine that this comment is included everywhere below where
    "system-wide" is mentioned. These 5 days are in addition to the
    development time for the individual config items.


    > 3a. Use ReplayGain tools such as MP3Gain and VorbisGain (you can
    > apt-get
    > these) to mark audio files with ReplayGain data on import. Write
    > an upgrade script to do it for existing files. The Ubuntu packages
    > must be updated with these new dependencies.
    > $$$ 3 days (Paul)

    There is no need to make ReplayGain a dependency; it is enough to add it
    as a Recommended (or Suggested, I'm not sure what the difference is)
    package. The audio player must accept non-ReplayGain tagged audio files
    in any case, since tagging may not be possible for linked files on
    non-writable volumes, or read-only media. (The estimate is OK though.)


    > 5. Playlog (Ticket #505)
    >
    > Total: 3-6 days

    This is for interface development only, right? The Scheduler has
    logging functionality already, which just needs to be fixed and spruced
    up (2 days); but Studio does not, and adding logging to it would be an
    extra 5 days. It's not clear whether we need this for MCM; they
    probably don't care about Studio.


    > 6. Play Count
    > - The play count will be stored as a metadata field.
    > Total: 5 days

    Why? This info can be got from the log table in the database. I'd say
    this is 0 days.


    > 9. Client list
    > We need a new interface and database structure for the "client list".
    > We will store the following info for each client:
    > - Client name
    > - Number of plays per hour
    > - Flag to indicate whether to reuse ads or not.
    > - Flag for whether this client's ads are active or inactive
    > - Misc text field

    I would add
    - PHP API and XML-RPC interface for adding, modifying and querying
    the client list

    There is no estimate here; I'd say 10 days, but it's Storage Server
    stuff, so I may be completely off.


    > 12. Auto-update Ads
    > When new ads are placed on the server, a script must be run to import
    > these ads into Campcaster. The playlist generator is then used to
    > generate a new list of ads. The old ads are removed from the
    > scheduler, and the new ones are substituted in their place.
    > $$$ 7 days (Paul)

    This is the issue we have talked about a couple times, but never
    decided. If we go with this "generate ad list and later replace ads"
    method, we need to include the ad selection criteria in the schedule,
    together with the ad itself, otherwise we won't know how to replace it.

    That's why I'm saying we should use virtual audio clips, which contain
    the selection criteria only, and the Storage Server would select the
    appropriate audio file when we call locstor.acquireAudioClip. This
    would reduce this item to 0 days, but add about the same amount of work
    to other items, giving no net change overall.


    > Playlist Generator Algorithm

    This needs a lot more work, but I like the general outline of the UI.

    Total: -2 +5 +2 -5 +10 = +10 days (from item 9, which had no estimate
    originally).

    Ferenc
Add a Comment