Gentoo ebuild
  • Vote Up0Vote Down importimport
    Posts: 0Member
    I'm trying to compile Livesupport-cvs on a gentoo system. I noticed many tools are already in portage.

    Is there already an effort to create an cvs-ebuild?

    My current problems are automake related problems, but it looks as if is fixable.

  • 19 Comments sorted by
  • livesupport-dev@eserver2.mdlf.org wrote:
    > This message was sent from: LS Development.
    >
    > ----------------------------------------------------------------
    >
    > I'm trying to compile Livesupport-cvs on a gentoo system. I noticed many
    > tools are already in portage.
    >
    > Is there already an effort to create an cvs-ebuild?

    we'll create an ebuild later on (I'm using gentoo as the development
    platform myself)

    > My current problems are automake related problems, but it looks as if is
    > fixable.

    make sure you have:

    export WANT_AUTOCONF=2.5
    export WANT_AUTOMAKE=1.7



    Akos

    ------------------------------------------
    Posted to Phorum via PhorumMail
  • If I can get xmlrpc++ to work out right, I'm going to build the cvs ebuilds (without the fetch for /tools directory)

    It seems that livesupport does look for boost, etc. out there, but something to patch too.

    Sorry for (maybe) asking something obvious, it looks livesupport uses gtk+gtkmm any plans to migrate it to gtk+2.6?

  • livesupport-dev@eserver2.mdlf.org wrote:
    > If I can get xmlrpc++ to work out right, I'm going to build the cvs ebuilds
    > (without the fetch for /tools directory)
    >
    > It seems that livesupport does look for boost, etc. out there, but
    > something to patch too.

    yes, some stuff needs to be patched, like unixODBC, etc. since then,
    some of our patches were incorportated into the main unixODBC source
    tree, for example. but not all.


    > Sorry for (maybe) asking something obvious, it looks livesupport uses
    > gtk+gtkmm any plans to migrate it to gtk+2.6?

    as you can see, we're using gtk+ 2.6.1 ...

    I believe there are ebuilds for these packages, so you could omit them
    when building the tools.

    what I wanted to do for the main makefile, is to have autoconf check for
    locally available libraries of sufficient version numbers, and omit the
    appropriate parts from the makefile when compiling tools. the
    PKG_CHECK_MODULES m4 macro could be used in configure.ac to check for
    existence of libraries that use pkg-config..


    Akos

    ------------------------------------------
    Posted to Phorum via PhorumMail
  • This is a multi-part message in MIME format.
    --------------040504050602060009010500
    Content-Type: text/plain; charset=UTF-8
    Content-Transfer-Encoding: 7bit

    First ebuild for xmlrpc++ (from our CVS). If someone can confirm this
    package has a 'normal' version number from SF... some changes need to be
    made.


    Stefan

    --------------040504050602060009010500
    Content-Type: text/plain;
    name="xmlrpc++-20040713.ebuild"
    Content-Transfer-Encoding: base64
    Content-Disposition: inline;
    filename="xmlrpc++-20040713.ebuild"

    IyBDb3B5cmlnaHQgMTk5OS0yMDA1IEdlbnRvbyBGb3VuZGF0aW9uCiMgRGlz
    dHJpYnV0ZWQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQ
    dWJsaWMgTGljZW5zZSB2MgoKaW5oZXJpdCBjdnMKCkRFU0NSSVBUSU9OPSJY
    TUxSUEMrKyIKSE9NRVBBR0U9Imh0dHA6Ly94bWxycGNwcC5zb3VyY2Vmb3Jn
    ZS5uZXQvIgoKRUNWU19TRVJWRVI9Im5ldGZpbml0eS01Lm1kbGYub3JnOi9o
    b21lL2N2cyIKRUNWU19VU0VSPSJhbm9ueW1vdXMiCkVDVlNfTU9EVUxFPSJs
    aXZlc3VwcG9ydC90b29scy8ke1BOfS8ke1B9IgoKTElDRU5TRT0iR1BMLTIi
    ClNMT1Q9IjAiCktFWVdPUkRTPSJ4ODYiCklVU0U9InNzbCIKCkFSQ0g9In54
    ODYiCgpSREVQRU5EPSIiClMwPSIke1dPUktESVJ9LyR7RUNWU19NT0RVTEV9
    L3NyYyIKUz0iJHtXT1JLRElSfS8ke0VDVlNfTU9EVUxFfS9zcmMvJHtQTn0i
    CgpzcmNfdW5wYWNrKCkgewoJY3ZzX3NyY191bnBhY2sKCWNkICR7UzB9Cgl0
    YXIgenhmICR7UzB9LyR7UH0udGFyLmd6CgljZCAke1N9CgllcGF0Y2ggLi4v
    Li4vZXRjL2luY29ycmVjdF9YbWxScGNWYWx1ZV9zdHJ1Y3RfdG1fY29udmVy
    c2lvbi5wYXRjaAoJZXBhdGNoIC4uLy4uL2V0Yy91bmluaXRpYWxpc2VkX1ht
    bFJwY1NvdXJjZV9zc2xfc3NsLnBhdGNoCgllcGF0Y2ggLi4vLi4vZXRjL3ht
    bHJwYysrLWF1dG9tYWtlLnBhdGNoCglleHBvcnQgV0FOVF9BVVRPTUFLRT0i
    MS43IiBXQU5UX0FVVE9DT05GPTIuNQoJY2htb2QgK3ggYXV0b2dlbi5zaAoJ
    Li9hdXRvZ2VuLnNoCn0KCnNyY19jb21waWxlKCkgewoJZW1ha2UgfHwgTUFL
    RU9QVFM9IiR7TUFLRU9QVFN9IC1qMSIgZW1ha2UgfHwgZGllICJNYWtlIGZh
    aWxlZCIKfQoKc3JjX2luc3RhbGwoKSB7CgltYWtlIGluc3RhbGwgREVTVERJ
    Uj0ke0R9IHx8IGRpZSAiSW5zdGFsbCBmYWlsZWQiCglkb2RvYyBDT1BZSU5H
    IElOU1RBTEwgUkVBRE1FLmh0bWwKfQo=

    --------------040504050602060009010500--

    ------------------------------------------
    Posted to Phorum via PhorumMail
  • Stefan,

    Thanks for the cvs-ebuild of xmlrpc++.

    we use some file conventions, in general described here:
    http://livesupport.campware.org/public_html/doc/developmentEnvironment/fileConventions.html

    On Thu, 2005-05-26 at 14:54, Stefan de Konink wrote:
    > First ebuild for xmlrpc++ (from our CVS). If someone can confirm this
    > package has a 'normal' version number from SF... some changes need to be
    > made.
    >
    >
    > Stefan
    >
    > ______________________________________________________________________
    > # Copyright 1999-2005 Gentoo Foundation
    > # Distributed under the terms of the GNU General Public License v2
    >
    > inherit cvs
    >
    > DESCRIPTION="XMLRPC++"
    > HOMEPAGE="http://xmlrpcpp.sourceforge.net/"
    >
    > ECVS_SERVER="netfinity-5.mdlf.org:/home/cvs"
    > ECVS_USER="anonymous"
    > ECVS_MODULE="livesupport/tools/${PN}/${P}"
    >
    > LICENSE="GPL-2"
    > SLOT="0"
    > KEYWORDS="x86"
    > IUSE="ssl"
    >
    > ARCH="~x86"
    >
    > RDEPEND=""
    > S0="${WORKDIR}/${ECVS_MODULE}/src"
    > S="${WORKDIR}/${ECVS_MODULE}/src/${PN}"
    >
    > src_unpack() {
    > cvs_src_unpack
    > cd ${S0}
    > tar zxf ${S0}/${P}.tar.gz
    > cd ${S}
    > epatch ../../etc/incorrect_XmlRpcValue_struct_tm_conversion.patch
    > epatch ../../etc/uninitialised_XmlRpcSource_ssl_ssl.patch
    > epatch ../../etc/xmlrpc++-automake.patch
    > export WANT_AUTOMAKE="1.7" WANT_AUTOCONF=2.5
    > chmod +x autogen.sh
    > ./autogen.sh
    > }
    >
    > src_compile() {
    > emake || MAKEOPTS="${MAKEOPTS} -j1" emake || die "Make failed"
    > }
    >
    > src_install() {
    > make install DESTDIR=${D} || die "Install failed"
    > dodoc COPYING INSTALL README.html
    > }

    ------------------------------------------
    Posted to Phorum via PhorumMail
  • Hello Frans,

    You are part of the OLON mailinglist as well aren't you?

    Frans van Berckel wrote:
    > Thanks for the cvs-ebuild of xmlrpc++.
    You're welcome.

    > we use some file conventions, in general described here:
    > http://livesupport.campware.org/public_html/doc/developmentEnvironment/fileConventions.html
    This is going to be a bit ambiguous for ebuilds, I guess we want them to
    get them into portage.


    Quote:
    using only tab characters -- no spaces

    ref:
    http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1

    versus

    no tabs - 4 spaces
    Don't use the tab character in text files - use 4 spaces instead for
    indentation.


    Stefan

    ------------------------------------------
    Posted to Phorum via PhorumMail
  • Hi,

    The last part of your questions is be for Akos.

    On Thu, 2005-05-26 at 15:45, Stefan de Konink wrote:
    > Hello Frans,
    >
    > You are part of the OLON mailinglist as well aren't you?

    No not jet, do you think this a good idea, I have not been part a local
    broadcasting.

    ------------------------------------------
    Posted to Phorum via PhorumMail
  • Frans van Berckel wrote:
    > No not jet, do you think this a good idea, I have not been part a local
    > broadcasting.
    I'm part of it, and mainly because PC-Radio is so bad behaving I first
    tried Rivendell (QT -> useless Wink and then found Livesupport. At the
    time I didn't have the systems nor allowance to test it for real.

    Basically if Livesupport can do the job for our local broadcast station
    we will migrate to it. One thing I don't know yet is if Livesupport
    supports Voicetracks, an easyway to pre-record your show just by
    recording Intro/Outro's.

    One other practical thing: How is hxclient supposed to be compiled, I do
    love the gstreamer idea... but since it isn't ready yet (and Livesupport
    doesn't link without it) I need some help compiling it Smile

    (an other good reason to not use helixplayer: it leaks memory and
    doesn't free memory in time... I currently use helixplayer for our
    'to-be-open-sourced-as-it-gets-published' Television scheduler, but need
    to migrate away from it too.)



    Stefan

    ------------------------------------------
    Posted to Phorum via PhorumMail
  • On Thu, 2005-05-26 at 16:27, Stefan de Konink wrote:
    > Frans van Berckel wrote:
    > > No not jet, do you think this a good idea, I have not been part a local
    > > broadcasting.
    > I'm part of it, and mainly because PC-Radio is so bad behaving I first
    > tried Rivendell (QT -> useless Wink and then found Livesupport. At the
    > time I didn't have the systems nor allowance to test it for real.
    Are they talking on the olon list about LiveSupport, i have done some
    publications on LiveSupport? I post on radioforum.nl about LiveSupport.
    http://www.radioforum.nl/viewtopic.php?t=7079

    > Basically if Livesupport can do the job for our local broadcast station
    > we will migrate to it. One thing I don't know yet is if Livesupport
    > supports Voicetracks, an easyway to pre-record your show just by
    > recording Intro/Outro's.

    Nice functions. The best you can do, post your feature request the our
    track and traceable bug and feature system. http://bugs.campware.org/

    > One other practical thing: How is hxclient supposed to be compiled, I do
    > love the gstreamer idea... but since it isn't ready yet (and Livesupport
    > doesn't link without it) I need some help compiling it Smile

    Akos can tell you later on when hxclient will be drop, he doing the job
    at the moment and nothing els, when its there...its....

    > (an other good reason to not use helixplayer: it leaks memory and
    > doesn't free memory in time... I currently use helixplayer for our
    > 'to-be-open-sourced-as-it-gets-published' Television scheduler, but need
    > to migrate away from it too.)

    ------------------------------------------
    Posted to Phorum via PhorumMail
  • Frans van Berckel wrote:
    > Are they talking on the olon list about LiveSupport, i have done some
    > publications on LiveSupport? I post on radioforum.nl about LiveSupport.
    > http://www.radioforum.nl/viewtopic.php?t=7079
    In the technical list your radioforum thread was referenced serveral
    times. I saw there was a LiveCD for LiveSupport, but I'm going to try to
    build one by myself using Gentoo Catalyst. Basically I want to get the
    Broadcast Partners hardware to support LiveSupport. So DCF, Faderstart
    etc. can be used without hardware migration.

    I also received the protocol specs of our Stargate RDS device, making
    that compatible with Livesupport could be another interesting way to
    make Livesupport better than Dalet, Carmen, PC-Radio, Rivendell, etc. Wink

    > Nice functions. The best you can do, post your feature request the our
    > track and traceable bug and feature system. http://bugs.campware.org/
    I will after I have tested the software. I want to put some coding
    effort in it too.

    > Akos can tell you later on when hxclient will be drop, he doing the job
    > at the moment and nothing els, when its there...its....
    Waiting is always a pleasant thing Smile


    Stefan

    ------------------------------------------
    Posted to Phorum via PhorumMail
  • On Thu, 2005-05-26 at 17:04, Stefan de Konink wrote:
    > Frans van Berckel wrote:
    > > Are they talking on the olon list about LiveSupport, i have done some
    > > publications on LiveSupport? I post on radioforum.nl about LiveSupport.
    > > http://www.radioforum.nl/viewtopic.php?t=7079
    > In the technical list your radioforum thread was referenced serveral
    > times. I saw there was a LiveCD for LiveSupport, but I'm going to try to
    > build one by myself using Gentoo Catalyst. Basically I want to get the
    > Broadcast Partners hardware to support LiveSupport. So DCF, Faderstart
    > etc. can be used without hardware migration.

    I think other stations and the NOB in the Netherlands will love this.
    How can i support you, i am into interfacing to hardware?

    > I also received the protocol specs of our Stargate RDS device, making
    > that compatible with Livesupport could be another interesting way to
    > make Livesupport better than Dalet, Carmen, PC-Radio, Rivendell, etc. Wink

    I have checkout RDS linux on Linux, more about is at
    http://bugs.campware.org/view.php?id=722

    > > Nice functions. The best you can do, post your feature request the our
    > > track and traceable bug and feature system. http://bugs.campware.org/
    > I will after I have tested the software. I want to put some coding
    > effort in it too.
    >
    > > Akos can tell you later on when hxclient will be drop, he doing the job
    > > at the moment and nothing els, when its there...its....
    > Waiting is always a pleasant thing Smile

    The biggest thing is be putting SMIL into the gStreamer player, it's not
    jet supported, they are talking 3 years about it but.... So we have to
    support Akos for the job.

    Frans van Berckel

    ------------------------------------------
    Posted to Phorum via PhorumMail
  • Frans van Berckel wrote:
    >>In the technical list your radioforum thread was referenced serveral
    >>times. I saw there was a LiveCD for LiveSupport, but I'm going to try to
    >>build one by myself using Gentoo Catalyst. Basically I want to get the
    >>Broadcast Partners hardware to support LiveSupport. So DCF, Faderstart
    >>etc. can be used without hardware migration.
    >
    > I think other stations and the NOB in the Netherlands will love this.
    > How can i support you, i am into interfacing to hardware?
    If I can spend sometime alone with our Broadcast pc, I'll try to find
    out on what kind of chips the custom PCI board is based on. But the
    point still is: first proof the product is better than the rest, the try
    to 'sell' it to new radiostations. I don't think Livesupport should be a
    migration product, that introduces 'expectations'.

    >>I also received the protocol specs of our Stargate RDS device, making
    >>that compatible with Livesupport could be another interesting way to
    >>make Livesupport better than Dalet, Carmen, PC-Radio, Rivendell, etc. Wink
    >
    > I have checkout RDS linux on Linux, more about is at
    > http://bugs.campware.org/view.php?id=722
    I don't know if the Stargate is UECP-490 compatible, but since I have
    the protocol handbook it shouldn't be too hard to make an UECP-490
    abstraction for Livesupport.

    > The biggest thing is be putting SMIL into the gStreamer player, it's not
    > jet supported, they are talking 3 years about it but.... So we have to
    > support Akos for the job.
    This all sound very common... whats the next step here? Make it
    SMIL-less or implement a working SMIL library? That last thing would be
    pretty neat...
    For my television thingie at first I'm going to support only the img/seq
    tags with no extensions. Maybe we could do the samething for gstreamer,
    just facilitate a basic level of SMIL support, to get it started.


    Stefan

    ------------------------------------------
    Posted to Phorum via PhorumMail
  • On Thu, 2005-05-26 at 18:03, Stefan de Konink wrote:

    > This all sound very common... whats the next step here? Make it
    > SMIL-less or implement a working SMIL library? That last thing would be
    > pretty neat...

    Shore i am common - because i don,t know.

    ------------------------------------------
    Posted to Phorum via PhorumMail
  • PFA+SGksPC9QPjxQPiZuYnNwOzwvUD48UD5JIGhvcGUgQWtvcyB3aWxsIHN0ZXAgaW4gaGVyZSBz
    byBJIGRvbnQgaGF2ZSB0byBhY3QgYXMgaGlzIHNwb2tlc21vZGVsLi4uIGJ1dCBpbiB0aGUgbWVh
    bnRpbWUsIHRoZSBsYXN0IEkgaGVhcmQgKGVhcmxpZXIgdG9kYXkpIGlzIHRoYXQgaGUgaXMgd29y
    a2luZyBvbiBpbXBsZW1lbnRpbmcgYSBzdWJzZXQgb2YgU01JTCByZWxldmFudCB0byBvdXIgbmVl
    ZHMsIHdoaWNoIG1ha2VzIHNlbnNlLjwvUD48UD4mbmJzcDs8L1A+PFA+QWtvcywgY2FuIHdlIGdl
    dCBzb21lIG1vcmUgZGV0YWlsIG9uIHdoYXQgeW91O3JlIHdvcmtpbmcgb24/PC9QPjxQPiZuYnNw
    OzwvUD48UD5kb3VnPC9QPjxQPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
    PT09PT09PTxCUj5NZWRpYSBEZXZlbG9wbWVudCBMb2FuIEZ1bmQ8QlI+PT09PT09PT09PT09PT09
    PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PEJSPkRvdWdsYXMgQXJlbGxhbmVzPEJSPkhl
    YWQgb2YgUmVzZWFyY2ggYW5kIERldmVsb3BtZW50PEJSPkNlbnRlciBmb3IgQWR2YW5jZWQgTWVk
    aWEtLVByYWd1ZSAoQ0FNUCk8QlI+TmEgdmluaWNuaWNoIGhvcmFjaCAyNGEvMTgzNCwgMTYwIDAw
    IFByYWd1ZSA2PEJSPkN6ZWNoIFJlcHVibGljPEJSPlRlbDogKyA0MjAgMiAzMzMzIDUzNTYsIEZh
    eDogKzQyMCAyIDI0MzEgNTQxOTxCUj5Nb2JpbGU6ICs0MjAgNzI0IDA3MyAzNjQ8QlI+PEEgSFJF
    Rj1odHRwOi8vd3d3Lm1kbGYtY2FtcC5uZXQ+aHR0cDovL3d3dy5tZGxmLWNhbXAubmV0PC9BPjxC
    Uj48QSBIUkVGPWh0dHA6Ly93d3cuY2FtcHdhcmUub3JnPmh0dHA6Ly93d3cuY2FtcHdhcmUub3Jn
    PC9BPjxCUj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08QlI+
    PEEgSFJFRj1odHRwOi8vd3d3Lm1kbGYub3JnPmh0dHA6Ly93d3cubWRsZi5vcmc8L0E+PEJSPj09
    PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwvUD48UD4mbmJzcDs8
    QlI+PEZPTlQgU0laRT0yPjxCPkZyYW5zIHZhbiBCZXJja2VsICZsdDtmYmVyY2tlbEB4czRhbGwu
    bmwmZ3Q7PC9CPjwvRk9OVD48QlI+PEZPTlQgU0laRT0yPjA1LzI2LzIwMDUgMDk6MTEgUE0gWkUy
    PC9GT05UPjxCUj48Rk9OVCBTSVpFPTI+UGxlYXNlIHJlc3BvbmQgdG8gbGl2ZXN1cHBvcnQtZGV2
    PC9GT05UPjxCUj48QlI+IDxGT05UIFNJWkU9Mj5Ubzo8L0ZPTlQ+IDxGT05UIFNJWkU9Mj5saXZl
    c3VwcG9ydC1kZXZAY2FtcHdhcmUub3JnPC9GT05UPjxCUj4gPEZPTlQgU0laRT0yPmNjOjwvRk9O
    VD4gPEJSPiA8Rk9OVCBTSVpFPTI+YmNjOjwvRk9OVD4gPEJSPiA8Rk9OVCBTSVpFPTI+U3ViamVj
    dDo8L0ZPTlQ+IDxGT05UIFNJWkU9Mj5SZTogW2xpdmVzdXBwb3J0LWRldl0gUmU6IEdlbnRvbyBl
    YnVpbGQ8L0ZPTlQ+PEJSPiA8QlI+PEJSPjwvUD48UD48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291
    cmllciI+T24gVGh1LCAyMDA1LTA1LTI2IGF0IDE4OjAzLCBTdGVmYW4gZGUgS29uaW5rIHdyb3Rl
    OjxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj4mZ3Q7IFRoaXMg
    YWxsIHNvdW5kIHZlcnkgY29tbW9uLi4uIHdoYXRzIHRoZSBuZXh0IHN0ZXAgaGVyZT8gTWFrZSBp
    dDxCUj4mZ3Q7IFNNSUwtbGVzcyBvciBpbXBsZW1lbnQgYSB3b3JraW5nIFNNSUwgbGlicmFyeT8g
    VGhhdCBsYXN0IHRoaW5nIHdvdWxkIGJlPEJSPiZndDsgcHJldHR5IG5lYXQuLi48QlI+PC9GT05U
    PjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+U2hvcmUgaSBhbSBjb21tb24gLSBi
    ZWNhdXNlIGkgZG9uLHQga25vdy48QlI+PC9GT05UPjwvUD4=

    ------------------------------------------
    Posted to Phorum via PhorumMail
  • mmm... I just used part of the gentoo ebuild script to get hxplay .a
    files. I just linked gLiveSupport... and I was shocked... a 30M
    executable... ok after a strip it left me with 2M but still BIG Razz

    Now I only need to read the documentation to get it actually started, to
    fix the semantic error in the configuration file. Or be a bit less
    enthousiastic and just go compile the rest too Wink

    > I hope Akos will step in here so I dont have to act as his spokesmodel... but in the meantime, the last I heard (earlier today) is that he is working on implementing a subset of SMIL relevant to our needs, which makes sense.
    If only Akos could implement the Audio smil part, we could probably
    combine effort in a full smil implementation. I would suggest looking at
    the latest version of SMIL.


    Stefan

    ------------------------------------------
    Posted to Phorum via PhorumMail
  • Stefan de Konink wrote:
    > This all sound very common... whats the next step here? Make it
    > SMIL-less or implement a working SMIL library? That last thing would be
    > pretty neat...

    I'm working on a _minimal_ SMIL implementation, that would support
    features important to LiveSupport:

    - only audio
    - seq and par elements
    - the audio element with the begin tag
    - fading (volume envelope) either through sound-level animation or some
    other means

    I understand this is just a small subset of SMIL, but this is all we
    need at the moment..


    Akos

    ------------------------------------------
    Posted to Phorum via PhorumMail
  • Stefan de Konink wrote:
    > If only Akos could implement the Audio smil part, we could probably
    > combine effort in a full smil implementation. I would suggest looking at
    > the latest version of SMIL.

    yes, SMIL 2 is much better...

    ------------------------------------------
    Posted to Phorum via PhorumMail
  • Akos Maroy wrote:
    > I understand this is just a small subset of SMIL, but this is all we
    > need at the moment..
    Correct, are you going to support something like 'absolute time' or
    'gliding to the end'?

    For example to place news exactly on :00:00 and commercials around
    :58:31? This could also be event based (Just load a new playlist), but
    then again, less problems, less errors.


    Stefan

    ------------------------------------------
    Posted to Phorum via PhorumMail
  • Stefan de Konink wrote:
    > Akos Maroy wrote:
    >
    >>I understand this is just a small subset of SMIL, but this is all we
    >>need at the moment..
    >
    > Correct, are you going to support something like 'absolute time' or
    > 'gliding to the end'?
    >
    > For example to place news exactly on :00:00 and commercials around
    > :58:31? This could also be event based (Just load a new playlist), but
    > then again, less problems, less errors.

    the idea is that you create playlists, that use their own relative time
    (start at 00:00:00, end whenever...), and you schedule these playlists
    in the scheduler for a specific time, when the playlimes get bound to an
    absolute time.

    ------------------------------------------
    Posted to Phorum via PhorumMail