1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies. Weitere Informationen

Problem bei Sendungsübergabe

Dieses Thema im Forum "Internetradio allgemein" wurde erstellt von TronicAccess, 23. November 2010.

Status des Themas:
Es sind keine weiteren Antworten möglich.
  1. TronicAccess

    TronicAccess Gesperrter Benutzer

    Hallo zusammen,

    Ich habe folgendes Problem:

    Seit ca. 1 Monat haben wir das Problem, das bei der Übergabe der Titel einfach abbricht, sobald ein Moderator bzw. DJ den Stream verlässt.

    Der Neue DJ der dann übernimmt, ist dann ca. 5 bis 10 sec. lang zu hören. Dann bricht der stream wieder ab und beginnt das Programm des neuen Djs von vorne, spielt es dann allerdings auch durch.

    Irgendwas stimmt hier mit dem Buffern nicht. Eventuell eine Einstellungssache ???

    Zu meinen Daten : Wir nutzen einen Linux Rootserver, mit ausreichend Ram und 500 MBit Anbindung. Da wir nur 500 Hörer haben ist also da kein Problem.

    Danke schon mal für eure Antworten !
  2. TronicAccess

    TronicAccess Gesperrter Benutzer

    AW: Problem bei Sendungsübergabe

    hat keiner eine Idee ??? wir haben mittlerweile den Server komplett neu gestartet .. und haben immer noch das gleiche Problem.

    TEUFELCHEN963 Benutzer

    AW: Problem bei Sendungsübergabe

    So einfach kann man da nichts sagen.
    Hast du die sc_serv.conf griffbereit ??
    (Stream IPs und PWs kannst du ja aus "X-en")
  4. TronicAccess

    TronicAccess Gesperrter Benutzer

    AW: Problem bei Sendungsübergabe

    Hier die sc_serv:

    ; SHOUTcast Distributed Network Audio Server configuration file
    ; Copyright (C) 1998-2004 Nullsoft, Inc.
    ; All Rights Reserved.
    ; Last modified Mar 17 2004

    ; If you want to manage multiple configurations, just copy
    ; this file to another name, and run sc_serv with that name
    ; such as:
    ; sc_serv.exe sc_leet.conf

    ; ***************************
    ; Required stuff
    ; ***************************

    ; MaxUser. The maximum number of simultaneous listeners allowed.
    ; Compute a reasonable value for your available upstream bandwidth (i.e. if
    ; you have 256kbps upload DSL, and want to broadcast at 24kbps, you would
    ; choose 256kbps/24kbps=10 maximum listeners.) Setting this value higher
    ; only wastes RAM and screws up your broadcast when more people connect
    ; than you can support.

    ; Password. While SHOUTcast never asks a listener for a password, a
    ; password is required to broadcast through the server, and to perform
    ; administration via the web interface to this server. This server should
    ; consist of only letters and numbers, and is the same server your broadcaster
    ; will need to enter in the SHOUTcast Source Plug-in for Winamp. THIS VALUE

    ; PortBase. This is the IP port number your server will run on. The
    ; value, and the value + 1 must be available. If you get a fatal error when
    ; the DNAS is setting up a socket on startup, make sure nothing else on the
    ; machine is running on the same port (telnet localhost portnumber -- if you
    ; get connection refused then you're clear to use that port). Ports < 1024
    ; may require root privledges on *nix machines. The default port is 8000.

    ; ***************************
    ; Optional Parameters
    ; ***************************

    ; ***************************
    ; Logging configuration
    ; ***************************

    ; LogFile: file to use for logging. Can be '/dev/null' or 'none'
    ; or empty to turn off logging. The default is ./sc_serv.log
    ; on *nix systems or sc_serv_dir\sc_serv.log on win32.
    ; Note: on win32 systems if no path is specified the location is
    ; in the same dir as the executable, on *nix systems it is in the
    ; current directory.
    ; LogFile=sc_serv.log

    ; RealTime displays a status line that is updated every second
    ; with the latest information on the current stream (*nix and win32
    ; console systems only)

    ; ScreenLog controls whether logging is printed to the screen or not
    ; on *nix and win32 console systems. It is useful to disable this when
    ; running servers in background without their own terminals. Default is 1

    ; ShowLastSongs specifies how many songs to list in the /played.html
    ; page. The default is 10. Acceptable entries are 1 to 20.

    ; TchLog decides whether or not the DNAS logfile should track yp
    ; directory touches. Adds and removes still appear regardless of
    ; this setting.
    ; Default is yes
    ; TchLog=yes

    ; WebLog decides whether or not hits to http:// on this DNAS will
    ; be logged. Most people leave this off because the DSP plug-in
    ; uses http:// calls to update titles and get the listener count,
    ; which takes up a lot of log space eventually. If you want to
    ; see people making hits on your admin.cgi or index pages, turn
    ; this back on. Note that this setting does NOT affect XML stats
    ; counters for hits to http:// pages.
    ; Default is no.
    ; WebLog=no

    ; W3CEnable turns on W3C Logging. W3C logs contain httpd-like accounts
    ; of every track played for every listener, including byte counts those listeners
    ; took. This data can be parsed with tools like Analog and WebTrends, or given
    ; to third parties like Arbitron and Measurecast for their reporting systems.
    ; Default is Yes (enabled).

    ; W3CLog describes the name of the logfile for W3C logging. Default logfile is
    ; sc_w3c.log, in the same directory wherever the DNAS gets started from.

    ; ***************************
    ; Network configuration
    ; ***************************

    ; SrcIP, the interface to listen for source connections on (or to make relay
    ; connections on if relaying). Can and usually will be ANY or
    ; (Making it will keep other machines from being able to
    ; broadcast using your shoutcast server )

    ; DestIP, IP to listen for clients on (and to contact yp.shoutcast.com)
    ; can and usually will be be ANY. If your machine has multiple IP addresses,
    ; set this to the one you want it to be accessed by.

    ; Yport, port to connect to yp.shoutcast.com on. For people behind caching
    ; webproxies, change this to the alternate port (666 is what it might be,
    ; check www.shoutcast.com if you have problems). Otherwise, leave this at 80.
    ; We're actively working on re-opening port 666, but as of release the only
    ; working port is port 80.

    ; NameLookups. Specify 1 to perform reverse DNS on connections.
    ; This option may increase the time it takes to connect to your
    ; server if your DNS server is slow. Default is 0 (off).

    ; RelayPort and RelayServer specify that you want to be a relay server.
    ; Relay servers act as clients to another server, and rebroadcast.
    ; Set RelayPort to 0, RelayServer to empty, or just leave these commented
    ; out to disable relay mode.
    ; RelayPort=8000
    ; RelayServer=

    ; ***************************
    ; Server configuration
    ; ***************************

    ; AdminPassword. This password (if specified) changes the
    ; behavior of Password to be a broadcast-only password, and
    ; limits HTTP administration tasks to the password specified
    ; here. The broadcaster, with the password above, can still
    ; log in and view connected users, but only the AdminPassword
    ; will grant the right to kick, ban, and specify reserve hosts.
    ; The default is undefined (Password allows control for both
    ; source and admin)

    ; AutoDumpUsers controls whether listeners are disconnected if the source
    ; stream disconnects. The default is 0.

    ; AutoDumpSourceTime specifies how long, in seconds, the source stream is
    ; allowed to be idle before the server disconnects it. 0 will let the source
    ; stream idle indefinately before disconnecting. The default is 30.

    ; ContentDir specifies the directory location on disk of where to stream
    ; on-demand content from. Subdirectories are supported as of DNAS 1.8.2.
    ; Default is ./content, meaning a directory named content in the same directory
    ; as where sc_serv was invoked from.
    ; ContentDir=./content

    ; IntroFile can specify a mp3 file that will be streamed to listeners right
    ; when they connect before they hear the live stream.
    ; Note that the intro file MUST be the same samplerate/channels as the
    ; live stream in order for this to work properly. Although bitrate CAN
    ; vary, you can use '%d' to specify the bitrate in the filename
    ; (i.e. C:\intro%d.mp3 would be C:\intro64.mp3 if you are casting at 64kbps).
    ; The default is no IntroFile
    ; IntroFile=c:\intro%d.mp3

    ; BackupFile can specify a mp3 file that will be streamed to listeners over
    ; and over again when the source stream disconnects. AutoDumpUsers must be
    ; 0 to use this feature. When the source stream reconnects, the listeners
    ; are rejoined into the live broadcast.
    ; Note that the backup file MUST be the same samplerate/channels as the
    ; live stream in order for this to work properly. Although bitrate CAN
    ; vary, you can use '%d' to specify the bitrate in the filename
    ; (i.e. C:\backup%d.mp3 would be C:\backup32.mp3 if you are casting at 32kbps).
    ; The default is no BackupFile
    ; BackupFile=C:\intro%d.mp3

    ; TitleFormat specifies a format string for what title is sent to the listener.
    ; For example, a string of 'Justin Radio' forces the title 'Justin Radio' even
    ; when the source changes the title. You can use up to one '%s' in the string
    ; which lets you contain the title from the source. For example, if your
    ; TitleFormat is 'Justin Radio: %s', and the source plug-in's title is
    ; 'Billy plays the blues', then the net title is
    ; 'Justin Radio: Billy plays the blues'. Note: only works on non-relay servers.
    ; The default is no format string.
    TitleFormat=%s | ClubRadio24 - More Radio More Music

    ; URLFormat specifies a format string for what url is sent to the listener.
    ; Behaves like TitleFormat (see above).
    ; The default is no format string.

    ; PublicServer can be always, never, or default (the default, heh)
    ; Any setting other than default will override the public status
    ; of the source plug-in or of a SHOUTcast server that is being relayed.

    ; AllowRelay determines whether or not other SHOUTcast servers will be
    ; permitted to relay this server. The default is Yes.

    ; AllowPublicRelay, when set to No, will tell any relaying servers not
    ; to list the server in the SHOUTcast directory (non-public), provided
    ; the relaying server's Public flag is set to default. The default is
    ; Yes.

    ; MetaInterval specifies how often, in bytes, metadata sent.
    ; You should really leave this at the default of 8192, but the option is
    ; provided anyway.

    ; *****************************
    ; Access Control
    ; *****************************

    ; ListenerTimer is a value in minutes of maximum permitted time for
    ; a connected listener. If someone is connected for longer than this
    ; amount of time, in minutes, they are disconnected. When undefined,
    ; there is no limit defined. Default is undefined.
    ; ListenerTimer=600

    ; BanFile is the text file sc_serv reads and writes to/from
    ; for the list of clients prohibited to connect to this
    ; server. It's automatically generated via the web
    ; interface.
    ; BanFile=sc_serv.ban

    ; RipFile is the text file sc_serv reads and writes to/from
    ; for the list of client IPs which are *ALWAYS* permitted
    ; to connect to this server (useful for relay servers).
    ; This file is automatically generated via the web
    ; interface. Note that if your server is FULL, and someone
    ; from a Reserved IP connects, the DNAS will force the person
    ; listening for the longest time off to make room for the new
    ; connection.
    ; RipFile=sc_serv.rip

    ; RIPOnly, when set to Yes, will only allow IP addresses listed in the Reserved
    ; IP list to connect and relay. All other connections for listening will be denied.
    ; This is really only useful for servers whose sole purpose is to provide the
    ; primary feed to all public relays. Setting this value to Yes also forces the
    ; server into Private mode, since listing this server in the directory would
    ; be pointless. Default is No.
    ; RIPOnly=No

    ; *****************************
    ; Extended Logging
    ; *****************************

    ; The old features previously at this location, HistoryLog and CurrentLog, are
    ; no longer used and succeded by W3C Logging and XML, respectively.

    ; ***************************
    ; Mass Configuration
    ; ***************************

    ; Unique: assigns a variable name for use in any config item which points to a
    ; file. Useful for servers running lots of SHOUTcast servers that have similar
    ; configuration parameters, excepting logfile names, banfile names, etc. Any
    ; parameter that takes a pathname can include the character $, which will
    ; substitute $ for the variable assigned here. Keep in mind that the unique
    ; variable can only be used after it is defined, so don't try to use a unique
    ; variable substitution in a path before you define it. For example, you
    ; could set:
    ; Unique=my_server
    ; and then define Log=/usr/local/shoutcast/$.log in an included configuration
    ; file. Default is Unique=$, so that by default any file with $ in the name
    ; won't substitute anything at all.

    ; Include: instructs the sc_serv to read from the named configuration file,
    ; *at the point of insertion of the Include statement*, and process as though
    ; the included file was part of itself. Note that all configuration parameters
    ; in the DNAS config file are processed first to last, so if an item is defined
    ; twice in a configuration, the last item to process will be the one that takes
    ; effect. For this reason, it's usually a good idea to use the Includes first
    ; in a config file.
    ; example:
    ; Include=/usr/local/shoutcast/common.conf
    ; Default is not applicable.

    ; *****************************
    ; Tweaks
    ; *****************************

    ; CpuCount is used to explicitly limit the DNAS to dominating a finite
    ; amount of processors in multiprocessor systems. By default,
    ; SHOUTcast creates one thread for every processor it detects in the
    ; host system, and assigns listeners equally across all the threads.
    ; In the event SHOUTcast doesn't correctly determine the number of
    ; CPUs in your host, or if you for whatever reason want to force
    ; the DNAS to not use other processors, you can say so here.
    ; Default behavior is to use as many processors as the DNAS detects on
    ; your system.
    ; CpuCount=1

    ; Sleep defines the granularity of the client threads for sending data.
    ; DNAS 1.7.0, per client thread, will send up to 1,024 bytes of data
    ; per socket (or less depending on the window available), and then
    ; sleep for the provided duration before repeating the whole process.
    ; Note that making this value smaller will vastly increase CPU usage on
    ; your machine. Increasing reduces CPU, but increasing this value too far
    ; will cause skips. The value which seems most optimal for 128kbps
    ; streaming is 833 (833 microseconds per client poll) on our test labs.
    ; We wouldn't recommend setting it any lower than 100, or any higher than
    ; 1,024. If you have a slower machine, set this number lower to fix
    ; skips.
    ; Default value is 833.
    ; Sleep=833

    ; CleanXML strips some whitespace and linefeeds from XML output which
    ; confuses some (poorly written) XML parsers. If you get XML rendering errors,
    ; try turning this on. Default is No (off).
    ; CleanXML=No

    Wir haben heute den ganzen Rootserver neu aufgesetzt. Könnte es an Debian liegen ??? Wir sind völlig verzweifelt weil das Problem weiterhin besteht....

    Hier eine Auswertung unserer Serverauslastung... Daran kann es ja net liegen oder ??

    top - 05:42:49 up 45 min, 2 users, load average: 1.72, 0.78, 0.34
    Tasks: 86 total, 1 running, 85 sleeping, 0 stopped, 0 zombie
    Cpu(s): 12.0%us, 0.2%sy, 0.0%ni, 87.3%id, 0.2%wa, 0.0%hi, 0.3%si, 0.0%st
    Mem: 8201540k total, 302844k used, 7898696k free, 17956k buffers
    Swap: 9703220k total, 0k used, 9703220k free, 168972k cached

    Danke für evtl. Ideen
  5. Oddy

    Oddy Benutzer

    AW: Problem bei Sendungsübergabe

    Mögliche Ursache könnten u.a. auch unterschiedliche Bitraten sein.

    Schönen Sonntag,

    TEUFELCHEN963 Benutzer

    AW: Problem bei Sendungsübergabe

    Hier mal die deutsche Erklärung was für was ist.

    Lies es dir mal durch, die Lösung liegt nahe.

    Wieso hast du eigentlich die Zeit für "AUTODUMPSOURCETIME" auf "0" gestellt ?
    In der deutschen Erklärung ist es ein wenig ungenau, denn "0" bedeutet zwar in der
    genauen Übersetzung das eigentlich nie getrennt wird.
    Aber technisch gibt es ja noch den Buffer im Server und der wird dann sofort getrennt.
    Beste Ergebnisse bekommst du mit der Werksvoreinstellung. (also "30")
    Dann hat man satte 30 sek. Zeit für eine Übergabe, das langt auch normalerweise.

    Wichtig dabei ist darauf zu achten, das ALLE Moderatoren/DJs die gleichen
    Samplingeinstellungen haben, denn sonst fliegt dir der Stream IMMER um die Ohren.
    (also zB 96 KBit / 44,1 kHz oder was auch immer ihr für einen Wert verwendet)

    Stell am besten alle Werte auf die in der deutschen Übersetzung ein.
    Damit funktioniert es.

    Was mir noch aufgefallen ist:
    URLFormat=http://www.clubradio24.dj << Das ist kein FQDN

    TitleFormat=%s | ClubRadio24 - More Radio More Music << wie lange soll denn der Tag noch werden ?

    Alles andere erkennst du durch aufmerksames lesen der deutschen Übersetzung selber.

    Schönen Sonntag noch und viel Spass beim testen.




    Voreinstellung: sc_serv.log
    Hier soll der Name und Pfadname angegeben werden, unter dem die SHOUTcast Logfiles abgespeichert werden. In einem Logfile werden alle Informationen gespeichert, die auch im SHOUTcast Server Monitor Fenster angezeigt werden.
    Auf Windows-Systemen ist der Pfad - wenn nichts weiter da steht - der Pfad in der die sc_serv.exe Datei liegt.
    Auf Unix-Systemen ist der Pfad das momentane Verzeichnis.


    Voreinstellung: 1
    RealTime besagt, das die Statusleiste mit den momentan aktuellen Infos über den Stream sekündlich gefüttert wird.


    Voreinstellung: 1
    Die Voreinstellung bewirkt, dass die Logs direkt auf dem Bildschirm im Montior Fenster angezeigt wird. Auf 0 gesetzt werden die Informationen im Hintergrund mitgeloggt. Dies ist sinnvoll für einen Server der nur im Hintergrund läuft (z.B. auf Unix-Systemen).


    Voreinstellung: 10
    Zulässige Werte : 1 - 20
    Anzahl der Songs die in der /played.html aufgeführt werden.


    Voreinstellung: 8000
    Die Portnummer, die Hörer benutzen, um sich auf dem Sever einzutunen. PortBase+1 darf nicht durch andere Programme genutzt werden, genauso wie die PortBase selbst. Muß nicht 8000 sein, wenn Du nur andere Ports frei hast, dann nimm z.B. 8020 oder 9000. Unix-Systeme haben 1024 als PortBase - dazu muß der Server als Benutzer root laufen.


    Voreinstellung: ANY
    Entweder ANY oder! ScrIP ermöglicht "source connections" und "relay connection" zu machen. Wenn ihr diese auf stellt, werden andere Leute Euren Computer nicht als Server benutzen können.


    Voreinstellung: ANY
    Sollte in den meisten Fällen ANY sein. Wenn Du mehrere IP adressen hast, trage hier die Adresse ein, unter welcher dein SHOUTcast Server erreichbar sein soll.


    Voreinstellung: 80
    Port über den Du Dich auf yp.shoutcast.com einloggst. Muß verändert werden wenn du hinter einem Proxy sitzt, ansonsten so lassen.


    Voreinstellung: 0
    0 ist die Voreinstellung und heißt "aus". 1 bedeutet "an" und es wird ein Reverse Lookup bei jeder Verbindung zum Server gestartet. Somit wird überprüft, ob der Servername des Verbindenden auch auf eine korrekte IP-Adresse aufgelöst wird. Verlangsamt den Verbindungsvorgang, wenn der Nameserver langsam ist.

    RelayPort= / RelayServer=

    Voreinstellung: 8000 und
    Auskommentiert und damit ausgeschaltet!
    Wenn ihr selbst eines Tages den RelayServer für andere spielen wollt, müsst ihr diese beiden Werte definieren (und die ; entfernen).


    Voreinstellung: 32
    Wieviele Höhrer sollen sich maximal auf Deinem Server einloggen können? 1024 ist das Maximum. Ziehe in Betracht, dass Deine Leitung um so größer sein sollte, je mehr Leuten Du potentiell die Chance geben möchtest, sich gleichzeitig bei dir einzuloggen.


    Voreinstellung: changeme
    "Ändermich" steht dort, damit Du das Passwort auch wirklich änderst. Das Passwort gibt denjenigen, die über Deinen Server als DJ streamen möchten einen Zugang.


    Voreinstellung: adminpass
    Beschneidet die Passwortfunktion von oben, wenn das AdminPassword aktiviert wird (Semikolon vor der Zeile entfernen). Ist Dein Computer Relay-Host für andere, die über deinen Server ein Stream senden, wirst Du ihnen das Passwort aus der vorhergehenden Einstellung geben. Damit können Sie sich auf der von Nullsoft bereitgestellten HTML-Seite für Broadcaster ansehen, wieviele Leute und wer genau eingeloggt ist.
    Das AdminPassword allerdings erlaubt auf dieser Seite auch Leute rauszuschmeißen und dauerhaft zu bannen, ist also ein Passwort mit mehr Rechten, welches dann nur der Serveradministrator (DU) inne hat.


    Voreinstellung: 0
    Definiert, ob die Hörerleitung gekappt wird, wenn der Quellstream abreißt.


    Voreinstellung: 30
    Zeit in Sekunden bis eine stehende Verbindung zwischen Hörer und Server gekappt wird, wenn kein Quellstream mehr kommt. 0 würde bedeuten, dass die Zeit unbestimmt ist, bis die Leitung gekappt wird.


    Voreinstellung, ausgestellt : c:\intro%d.mp3
    Man kann am Anfang seines Radioprogramms jedem Höhrer ein Jingle o.ä. , eben eine Startup MP3-Datei vorspielen. Ist Introfile nicht mit Semikolon ausgestellt, definiert der Pfad hinter dem "=" wo die MP3 Intro-Datei liegt (%d ist Platzhalter für die kbps in denen die MP3-Datei enkodiert wurde, also z.B Intro32.mp3, wenn die Datei 32kbps hat).


    Voreinstellung, ausgestellt: C:\intro%d.mp3
    Die Backup MP3-Datei wird gesendet, wenn der Quellstream abreißt. Dies ist praktisch der Notbehelf, wenn irgendetwas schiefgeht und man den Höhrern zumindest mitteilen möchte, dass man noch da ist und es gleich weitergeht. Der Pfad gibt wieder an, wo sich die MP3-Datei auf deinem Computer befindet.


    Voreinstellung, ausgestellt: TrashCore Radio: %s
    Definiert welcher Radioname (TrashCore Radio) jeweils vor dem Songtitel (%s) erscheint. Wenn der Songtitel des Quellstreams (also von jemandem der deinen Computer als Server benutzt) "White punx on dope" heisst und Dein Radioname wie oben definiert ist, bekommen die Höhrer "TrashCore Radio: White punx on dope" als Titel angezeigt.


    Voreinstellung, ausgestellt: http://www.server.com/redirect.cgi?url=%s
    Ist ausgestellt, definiert welche URL dem Höhrer gesendet wird. Arbeitet wie TitleFormat (s.o.)


    Voreinstellung: =default
    always, never oder default sind mögliche Werte die hier auftauchen können. Alles andere als die Voreinstellung: default schaltet den Titelplugin aus.


    Voreinstellung: 8192
    Definiert, wie oft in Bytes Metadata gesendet wird. So lassen !
  7. Oddy

    Oddy Benutzer

    AW: Problem bei Sendungsübergabe

    Lustisch. Eine Lösung für die Lösung... :wall:

    Hast du die von mir in Fettschrift markiere AutoDumpSourceTime=0, sowie den Hinweis auf die Bitrate überlesen?

    T'schuldigung, aber ob da jetzt ichhabauchne.url oder sonst etwas steht, hat mit dem vom TE beschriebenen Problem wenig zu tun.

    So lang, wie es jeder eben haben möchte. Es gibt ja zum Glück horizontale Scrollbalken :D


    TEUFELCHEN963 Benutzer

    AW: Problem bei Sendungsübergabe

    Ich habe das nicht übersehen, falls es dein ansinnen war den Kollegen zum selber nachdenken zu animieren,

    Bei der URL ist mir das nur aufgefallen, natürlich hat das mit dem Urproblem wenig bis gar nichts zu tun.
    Naja, die deutsche Übersetzung der .conf sollte ihm zumindest weiterhelfen.

    Gruß Thomas
  9. TronicAccess

    TronicAccess Gesperrter Benutzer

    AW: Problem bei Sendungsübergabe

    Erst mal Danke für die Antworten....

    Zum Thema.....

    Wir senden alle auf 128 Kbps und habe auch alle die gleichen Einstellungen. Die Autodump spielt bei meinem Problem auch keine Rolle, da niemand vom Stream fliegt. Ich versuch nochmal das Problem genauer zu erläutern:

    Wir Stoppen den Stream und starten diesen Komplett neu. Die Playlist geht auf Sendung... ca. 40 Sec.... Dann Springt die PL wieder auf Anfang und läuft durch. Genau so wenn ein Dj nun eine Sendung übernimmt. Die neue Sendung beginnt ca. 30 bis 40 Sec... dann Springt es wieder auf Anfang und die Sendung läuft durch.

    Ich Betreibe das Radio nun schon seit 5 Jahren und hatte bisher gedacht so ziemlich Fit zu sein was Konfigurationen angeht, zumal auf dem gleichen Server noch einige meiner Kunden liegen, die das gleiche Problem haben. Interessant ist allerdings das es nicht bei jedem so ist, obwohl die Config EXAKT GLEICH ist !!!!

    Ich nehme mittlerweile an das es an der Hardware liegt. auch wenn ich mir das echt nicht erklären kann...
  10. Surfmusik

    Surfmusik Benutzer

    AW: Problem bei Sendungsübergabe

    Läuft auf dem Server evtl. das am-plugin (Audimark) ?
  11. Surfmusik

    Surfmusik Benutzer

    AW: Problem bei Sendungsübergabe

    Es liegt am am-plugin. Ist bei Audimark auf der ToDo-List.

    TEUFELCHEN963 Benutzer

    AW: Problem bei Sendungsübergabe

    Ein Grund mehr Audimark zu meiden. (der erste Grund ist die Exklusivitätsklausel in deren Vertrag)
  13. ForenKater

    ForenKater Benutzer

    AW: Problem bei Sendungsübergabe

    Ich bin von Audimark auch nicht gerade begeistert - wer will schon unkontrollierbare Fremdsoftware auf seinem Server laufen haben.
  14. audimark_TR

    audimark_TR Benutzer

    AW: Problem bei Sendungsübergabe

    Hallo zusammen,

    das Problem mit der Sendeschleife ist soweit gelöst. Gibt es hierzu immer noch Probleme, bitte ich um eine kurze Info.

    Bzgl. der unkontrollierbaren Fremdsoftware:

    Das Plugin ist genau so eine Fremdsoftware wie SHOUTcast auch. Es ist geplant, alle Funktionalitäten in der nächsten Zeit ordentlich auf der audimark Website zu dokumentieren. Da dies in einer größeren Dokumentation eingebettet sein soll, ist es doch viel Arbeit und nicht sofort machbar. Wir klären jedoch gerne über die Funktionalitäten auf, einfach kurz bei mir melden.


    Thomas Rogg
  15. TronicAccess

    TronicAccess Gesperrter Benutzer

    AW: Problem bei Sendungsübergabe

    So ich meld mich dann auch nochmal zu Wort.

    Audimark hat den Fehler verursacht. Nicht nur das die unausgereifte Technik dazu geführt hat, das einigen unserer DJ´s das Trommelfell im wahrsten Sinne um die Ohren geflogen ist. Nein es hat auch dazu geführt, dass wir als Provider Kunden verloren haben.

    Wie ich in diesem Beiträgen schön einige male geschrieben habe, haben wir im Vorfeld alles getan um einen Möglichen Fehler aus zu machen. Nachdem Herr Rogg sich dann am 17.12. via Mail zu diesem Problem äusserte wurde uns die Sachlage erst bewusst. Wir haben das Plugin aus gestellt und alles lief reibungslos.

    Was ich allerdings eine absolute Frechheit finde ist, das SIE Herr Rogg, nicht bereit sind unseren entstandenen Schaden zu begleichen. Wir haben mittlerweile einen Rechsanwalt beauftragt.

    Fazit: Für uns ist Audimark absolut inkompetent. Ich kann doch keine Software anbieten die nicht funktioniert. Und wenn das schon passiert, dann steh ich als Unternehmer für den entstanden schaden ein. Nein, Herr Rogg, Sie wollen die harte Tour !
  16. TronicAccess

    TronicAccess Gesperrter Benutzer

    AW: Problem bei Sendungsübergabe

    Auch wenn ich mich jetzt rein Steiger:

    Es sollte wohl aus meinem Kommentar hervor gegangen sein, das wir als Unternehmen, und als Webradio keinerlei Dienstleistungen mehr von Audimark nutzen werden. Allein die Aussage:
    Wenn wir unseren Kunden mit so einem Spruch kommen, kann ich direkt die Insolvenz anmelden. Der Unterschied ist nur folgender:

    Die meisten Webradios haben keine Sponsoren. Daher sind sie auf Sie angewiesen Herr Rogg. Und das nutzen Sie schamlos aus !

    Nun, um das ganze zu einem Ende zu bringen:

    - Alle Webradios die ähnliche Verluste oder Einbussen hatten sollen sich mal bei mir melden.
    - Kennt jemand alternativen zu Audimark ? Wenn nicht programmieren wir eine !

    bei Fragen : info@xhosting24.de

    Allen von herzen einen guten Rutsch, und erfolgreiches Jahr 2011
  17. ForenKater

    ForenKater Benutzer

    AW: Problem bei Sendungsübergabe

    Hm, ich glaube aber, eine Hasstyrade ala "Massenklage" oder Ähnlich - die es in DE nicht gibt - ist hier total fehl am Platz. Ihr müsst auch erstmal einen echten wirtschaftlichen Schaden NACHWEISEN etc. Da wirds bei den meisten Radingern schon schwer ;)
  18. TronicAccess

    TronicAccess Gesperrter Benutzer

    AW: Problem bei Sendungsübergabe

    Sry, will keine Hasstyraden los treten. Sammelklagen gibts in DE nicht .. Korrekt. Wie schon gesagt, wir können den Schaden leider Gottes sehr genau beziffern. Das Fängt an bei Arbeitsleistung, Wartungskosten, und Einnahmeausfälle. Ich mein wir reden hier über knapp 1000 Euro. Für uns als kleines und junges Unternehmen keine Kleinigkeit.

    Ich bin nur der Meinung, sollte es andere auch getroffen haben, so würde ich diese wohl unterstützen. Wie schon gesagt, ich finde es einfach nur Fair. Wir hatten auch mal einen Software Fehler in unseren Programmierungen. Und wir haben freiwillig unseren Kunden eine Rückerstattung gegeben. Zumal ich Herrn Rogg einen Vergleich angeboten hatte.

    Sei es drum.
  19. Oddy

    Oddy Benutzer

    AW: Problem bei Sendungsübergabe

    Wir hatten auch Probleme mit der Software und folglich einen Mehraufwand, da wir das Plugin auf den Servern deaktivieren mussten. Erstaunlicherweise leben wir aber noch, haben keinen körperlichen Schaden dadurch erlitten und unsere Station sendet nach wie vor.

    Wenn ich das lese, stell' ich mir doch glatt die Frage, ob mir wohl Microsoft® bei einem Programmabsturz und dem damit verlustig gegangenen Kauf in einer eBay-Auktion, auch Schadenersatz leisten würde... :D

    Have fun in 2011,
  20. AW: Problem bei Sendungsübergabe

    Du redest hier von einem Unternehmen und von Einnahmenausfällen.
    Auf deiner Seite finde ich keine Steuernummer.
    Die Erwähnung der gültigen Mehrwertsteuer in deinen Preisen ist für mich auch nicht ersichtlich.
    Nur der Hinweis, dass du Mitglied bei der IHK bist, sagt nocht nichts über dein Unternehmertum.
    Ebenso gibt es entsprechende Verträge, die du vor der Zusammenarbeit mit o.g. Firma sicher durchgelesen und unterzeichnet hast.

    Alles Gute

  21. TronicAccess

    TronicAccess Gesperrter Benutzer

    AW: Problem bei Sendungsübergabe

    Lieber AJ,

    Bestell doch einfach mal was bei uns... Dann siehst du die Steuernummer ;) Und zum Thema Mehrwertsteuer... Ich darf diese nicht ausweisen. Wenn du erfahren möchtest warum, stehe ich dir gerne via PN zur Verfügung.

    Ist aber ok. Ich werd das Thema auf sich beruhen lassen, zumindest hier im Forum.

    Euch allen ein gesundes und erfolgreiches Jahr 2011
  22. ForenKater

    ForenKater Benutzer

Status des Themas:
Es sind keine weiteren Antworten möglich.

Diese Seite empfehlen