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

sc_trans: Problem

Dieses Thema im Forum "Internetradio- und Heimstudio-Software" wurde erstellt von Montague, 11. Januar 2008.

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

    Montague Benutzer

    schönen guten Tag!

    Situation vorab:
    Ich miete einen RootDS mit Debian4. Auf diesem Server läuft icecast1 und shoutcast ohne Probleme. Auch die Webradiomoderatoren können ohne Probleme streamen. Ich habe sc_trans richtig konfiguriert und es startet ohne Probleme. sc_trans streamt mir meine mp3-Files. Er ist konfiguriert für 128kBit/44,1kHz/Stereo.
    Aber der Stream "ruckelt" - sprich, er hat Aussetzer, sodass die Player teilweise komplett vom Stream fallen. Bei Sendungen, die ein Moderator streamt, gibt es dieses Problem nicht. Nur mir sc_trans.
    Das gleiche Problem hat "shout" - ein ähnliches Programm wie sc_trans.

    Info
    Die CPU-Auslastung ist unter 20%. Die Systemauslastung unter 5%.
    Das Problem ist erst kürzlich (seit Jahresbeginn) aufgetreten. Er "streamte" ein Jahr lang ohne Probleme.

    sc_trans schreibt mir (pro Datei): <01/11/08@02:12:30> Warning: input file samplerate is -1208007943 Hz, must be 44100!

    Wenn ich jetzt in der config Datei die Inputsamplerate auf 44100 definiere, dann schreibt er mir (pro Datei):
    <01/11/08@02:12:30> Warning: input file samplerate is -44100 Hz, must be 1208007943!

    Fühl mich ein wenig verarscht.. :wall:
    Vielleicht liegt es an die mp3-Files?
    Ich hab die TAGs geprüft, ich hab die Bitraten und die Frequenzen überprüft.
    Problem bestand weiterhin..
    Dann hab ich die mp3s neu convertiert, sogar mit verschiedenen Programmen, da vielleicht ein Programm einen Murks dreht.
    Immer wieder die obrige Fehlermeldung!

    Interessant ist, wenn ich sc_trans auf 96000 Bit konfigurier, schreibt er mir zwar die Meldung, aber der Stream ruckelt nicht. Das ist aber keine Lösung für mich.

    Ist evtl. der Server zu schwach?
    1000MHz
    768MB

    Kann aber auch nicht sein, da er ein Jahr ohne Probleme lief.

    Die Anzeige top bringt mir folgende Meldung:
    3% CPU für sc_trans
    der Rest liegt bei 0% (hab alles unnötige aus dem Autostart genommen)

    Mem: 2004164k total, 1973392k used, 30772k free, 66524k buffers
    Swap: 4096564k total, 592k used, 4095972k free, 731156k cached

    Der Speicher ist bei Linux wohl immer fast voll, da ich gelesen hab, dass Linux alles in den Arbeitsspeicher läd was es reinbringt.
    Weiteres hab ich gelesen, dass dieses "swappen" nicht gut sei, damit kenn ich mich aber zu wenig aus.

    Die Suchfunktion bei radioforen.de hat mich nicht wirklich weitergebracht.
    Bei Google fand ich einen ausländischen Beitrag, mit genau dem selben Problem. Die Antwort darauf war aber nur, dass eben einer dieses Problem auch hatte und dann zu ices umgestiegen ist.

    Jemand eine Idee?

    ganz liebe Grüße in die Runde :)
     
  2. Pegasus

    Pegasus Benutzer

    AW: sc_trans Problem

    Ja, mach ein Update auf Etch und stell auf icecast2 um.

    Ansonsten ist ohne Configs wenig zu sagen. Ich vermute aber den Fehler dennoch im System. Allerdingsbringt eine fehlersuche erst nach den genannten Updates was.
     
  3. Montague

    Montague Benutzer

    AW: sc_trans: Problem

    Es handelt sich bereits um Debian 4 ETCH, außerdem ist icecast1 als Paket schon in der Distribution enthalten. Dieses lief auch 1 Jahr lang ohne Probleme. Daher glaub ich nicht dass die Konfiguration der Programme schuld ist. Der Server ist auch neu aufgesetzt.

    Warum icecast1?
    Nun, shoutcast hat eine Verzögerung von 30-60 Sekunden. Icecast1 sowie Icecast2 von maximal 1-3 Sekunden. Das ist uns bei Livesendungen wichtig. Wir übertragen auch Konzerte live. Da es oft eine "WarmUp-Sendung" zur Übertragung gibt, schalten wir dann live rüber zur Veranstaltung.

    (Sprich: Der Moderator der die WarmUp-Sendung macht, hört einfach einen anderen Mountpoint nebenbei ab, und schiebt zur gegebenen Zeit den Regler am Pult hoch, somit hört man in der WarmUp-Sendung, die andere Sendung. Verzögerungsfrei, kann der Moderator vom Event seine Moderation machen, wenn er fertig ist, gibt er zurück in die Zentrale - dort kommt der Regler dann wieder runter. Ich hoffe es ist nachvollziehbar)

    Natürlich funktioniert das auch mit Icecast2, aber bei der 2er Version gibt es kein Telnet mehr, womit man die clients von einem mount zum anderen schieben kann, ohne dass sie vom Stream fallen. (Ja, mittels Webadmin, aber die Hörer connecten trotzdem zum anderen Mountpoint) Derzeit greift der Hörer immer nur IP:port ab, und wir können bei icecast1 definieren, welcher source die höchste Priorität hat (modify ID -P Priorität). Der Hörer hört immer den source mit der höchsten Priorität. Findet ein source-Wechsel statt, erhöhen wir die Priorität vom anderen Moderator (neue Hörer connecten automatisch zum neuen source) und schieben die alten Hörer mittels switch -a alteID neueID auf den neuen source.

    Verzögerungsfrei, ohne dass ein Hörer vom Stream fällt. Das gibts bei icecast2 in dieser Form definitiv nicht. Bei icecast2 muss die Url zum Stream mit dem mountpoint angegeben werden. icecast2 hat viel weniger Funktionen als die 1er Versionen. Ich verwende die "neueste" 1er.

    Hier die gewünschten Configfiles (gekürzt)
    ; ServerIP/ServerPort are the target server to send to
    ServerIP=127.0.0.1
    ServerPort=8000

    ; Password is the password on the sc_serv you're sending to.
    Password=XXXXX
    ; Logfile optionally denotes a text file to log sc_trans to. a kill -HUP
    ; will force a close and re-open of this file (but will also cease logging to
    ; the console)
    LogFile=sc_trans.log

    ; Shuffle the playlist
    Shuffle=1

    ; Bitrate/SampleRate/Channels recommended values:
    ; 8kbps 8000/11025/1
    ; 16kbps 16000/11025/1
    ; 24kbps 24000/22050/1
    ; 32kbps 32000/22050/1
    ; 64kbps mono 64000/44100/1
    ; 64kbps stereo 64000/22050/2
    ; 96kbps stereo 96000/44100/2
    ; 128kbps stere0 128000/44100/2
    Bitrate=128000
    SampleRate=44100
    Channels=2
    ; Quality is from 1-10. 1 is best, 10 is fastest.
    Quality=10

    ; Mode=0 for none, 1 for 100/100->100/0, 2 for 0/100->100/0
    CrossfadeMode=1
    ; Length is ms.
    CrossfadeLength=8000

    UseID3=1
    Public=0

    & icecast1 (gekürzt)
    max_clients 1000
    max_clients_per_source 250
    max_sources 5
    max_admins 5
    throttle 10.0

    use_meta_data 0
    streamurllock 0
    streamtitletemplate %s
    streamurl http://XX.XX.XX.XX:8000/
    nametemplate %s
    desctemplate %s

    mount_fallback 1

    #icydir yp.shoutcast.com
    #icydir yp.breakfree.com
    #icydir yp.musicseek.net
    #icydir yp.van-pelt.com //diese Optionen möchte ich nicht, daher #
    #icydir yp.radiostation.de
    #directory yp.icecast.org
    #directory yp.mp3.de
    #touch_freq 5

    #hostname XX.XXX.XX.XX

    port 8000
    port 8001

    server_name XX.XXX.XX.XX

    force_servername 0

    #logfile icecast.log //will ich nicht, daher #
    #accessfile access.log
    #usagefile usage.log
    #logfiledebuglevel 0
    #consoledebuglevel 0

    reverse_lookups 0
    console_mode 3
    client_timeout 0
    kick_clients 0
    #staticdir c:\windows\desktop
    #staticdir /usr/share/icecast/static
    #templatedir #/usr/share/icecast/templates
    #logdir /var/log/icecast
    #stats_log stats.log
    #statshtml_log stats.html
    #stats_time 60

    Ja, der Rest ist ohnehin irrelevant.

    Ich muss betonen dass sc_trans mit 96kBit 44,1kHz zwar die gleiche WARNING-Meldung liefert. Aber der Stream nicht mehr Aussetzt bzw. Ruckelt.

    Vielleicht liegt es an der Datenmenge? Gibts da eine Begrenzung pro Client auf den Root. Glaub ich aber auch nicht, da ich mit meiner Internetanbindung mit maximaler Geschwindigkeit Daten hoch und runter laden kann.

    Ich glaub auch nicht dass der Server zu schwach ist, es lief mit schwächeren Servern, auch ohne Probleme.

    Ich würde auch den Zugriff zum Root erlauben, wenn jemand denkt, dass er das Problem beheben kann. Immerhin leidet das Projekt sehr darunter.

    :(
     
  4. Pegasus

    Pegasus Benutzer

    AW: sc_trans: Problem

    Zu deinen Aussagen zu Icecast2 sag ich jetzt mal nichts, da du offensichtlich die Doku nicht richtig gelesen hast. Das aber nur nebenbei, Wenn du Icecast1 nutzen willst, schlecht ist das Programm nicht ;)

    Ansonsten stellt sich die Frage, ob der sc_trans umkodieren soll oder nur den Stream erzeugen. Diese Einstellung hast du dummerweise abgeschnitten. Beim Umkodieren würd ich sagen, nimm nen anderen Codec oder nuztz den streamTranscoderv3.

    Mehr fällt mir dazu leider nicht ein und die Zeit, deinen Server umzukrempeln, hab ich momentan einfach nicht. Vielleicht kann jemand anders helfen. :)
     
  5. Montague

    Montague Benutzer

    AW: sc_trans: Problem

    Ich mag icecast2 absolut nicht. ;)

    Da ich dachte, ich bin ein ganz ein schlaues Bürschlein, hab ich nur mp3-Files in 128kBit 44,1 kHz Stereo hochgeladen, einfachst in Zahlen benannt (01.mp3 usw.) dass sc_trans weniger arbeit hat und es zu keinen Lesefehlern der Playlist kommt.

    sc_trans soll die mp3s in der Playlist nicht in eine andere "Qualität" (Bitrate) konvertieren. Es soll nur die mp3s in gleicher Qualität zu icecast streamen.

    Was es in minderwertiger Qualität (96kBit) auch trotz Warnmeldung ohne Ruckeln macht.

    Tut mir Leid, ich dachte die letzten Konfigurationen seien sowieso irrelevant.
    Hier nochmal die komplette sc_trans.conf:

    ; Sample sc_trans/0.35-j config file
    ; j.frankel 12/05/00
    ; t.pepper 10/31/00
    ; (relays not supported, yo)
    ;
    ; sc_trans operates in one of two modes, either reading mp3s off disk, decoding,
    ; re-encoding, and then broadcasting them, or relaying from a shoutcast server,
    ; transcoding to a lower bitrate, and broadcasting to a new server.

    ; sc_trans accepts the following signals:
    ; HUP - flush logfiles (close and reopen) -- will make console logging stop
    ; WINCH - jump to next song
    ; USR1 - reload playlist off disk (will not interrupt current playing stream)
    ; USR2 - toggle shuffle on/off
    ; TERM - normal sc_trans shutdown (clean)

    ; PlaylistFile (required EVEN IF RELAYING) - playlist file (to create, use
    ; find /path/to/mp3/directory -type f -name "*.mp3" > playlist_filename.lst
    PlaylistFile=example.lst

    ; ServerIP/ServerPort are the target server to send to
    ServerIP=127.0.0.1
    ServerPort=8000

    ; Password is the password on the sc_serv you're sending to.
    Password=xxxxxxx

    ; StreamTitle/URL/Genre define the data that appears on the directory and in the
    ; stream info.
    StreamTitle=Vl. später ;)
    StreamURL=
    Genre=Rock Funk Soul Punk Indie Alternativ Oldie

    ; Logfile optionally denotes a text file to log sc_trans to. a kill -HUP
    ; will force a close and re-open of this file (but will also cease logging to
    ; the console)
    LogFile=sc_trans.log

    ; Shuffle the playlist
    Shuffle=1

    ; Bitrate/SampleRate/Channels recommended values:
    ; 8kbps 8000/11025/1
    ; 16kbps 16000/11025/1
    ; 24kbps 24000/22050/1
    ; 32kbps 32000/22050/1
    ; 64kbps mono 64000/44100/1
    ; 64kbps stereo 64000/22050/2
    ; 96kbps stereo 96000/44100/2
    ; 128kbps stere0 128000/44100/2
    Bitrate=128000
    SampleRate=44100
    Channels=2
    ; Quality is from 1-10. 1 is best, 10 is fastest.
    Quality=10


    ; Mode=0 for none, 1 for 100/100->100/0, 2 for 0/100->100/0
    CrossfadeMode=1
    ; Length is ms.
    CrossfadeLength=8000

    UseID3=0

    ; Public determines whether or not this station will show up in the directory
    Public=0

    ; Put stuff here for user interaction (AOL IM, ICQ, IRC)
    ;AIM=AIMHandle
    ;ICQ=
    ;IRC=shoutcast

    Mehr, gabs da nicht.. :confused: ..hatte immer funktioniert.
     
  6. Pegasus

    Pegasus Benutzer

    AW: sc_trans: Problem

    Ganz banal: Hast du den Server mal neu gebootet?
    Ich muss zugeben, mir gehen echt die Ideen aus, ausser es liegt am MP3-Codec. Hast du lame drauf?
     
  7. Montague

    Montague Benutzer

    AW: sc_trans: Problem

    >mal neu gebootet? mehrmals!

    unter apt-cache search lame
    krieg ich folgende Listung:

    arson - KDE frontend for burning CDs
    caca-utils - text mode graphics utilities
    cmt - Computer Music Toolkit (cmt) a collection of LADSPA plugins
    darkice - Live audio streamer
    electricsheep - screensaver showing collective dream of sleeping computers
    epic4-script-light - Light - It's Just Not Lame
    flamerobin - graphical database administration tool for Firebird DBMS
    flamethrower - Multicast file distribution utility
    glame - versatile audio processor
    hardware-monitor - Monitor applet for the Gnome panel
    libavifile-0.7c2 - shared libraries for AVI read/writing
    libcarp-clan-perl - Perl enhancement to Carp error logging facilities
    libglib-perl - Perl interface to the GLib and GObject libraries
    libgnome2-canvas-perl - Perl interface to the GNOME canvas library
    libgnome2-gconf-perl - Perl interface to the GNOME GConf library
    libgnome2-perl - Perl interface to the GNOME libraries
    libgnome2-print-perl - Perl interface to the GNOME Printing libraries
    libgnome2-vfs-perl - Perl interface to the 2.x series of the GNOME VFS library
    libgnome2-wnck-perl - Perl interface to the Window Navigator Construction Kit
    libgtk2-gladexml-perl - Perl interface to use user interfaces created with glade-2
    libgtk2-perl - Perl interface to the 2.x series of the Gimp Toolkit library
    libgtk2-perl-doc - Perl interface to the Gtk 2.x series (documentation files)
    libgtk2-trayicon-perl - Perl interface to fill the system tray
    libgtk2-traymanager-perl - Perl interface to fill the system tray
    libtwolame-dev - MPEG Audio Layer 2 encoder (development files)
    libtwolame0 - MPEG Audio Layer 2 encoding library
    ripit - Textbased audio cd ripper
    ripperx - a GTK-based audio CD ripper/encoder
    soundconverter - convert sound files to other formats
    swh-plugins - Steve Harris's LADSPA plugins
    systemimager-server-flamethrowerd - SystemImager boot binaries for ia64 client nodes
    toolame - MPEG-1 layer 2 audio encoder
    twolame - MPEG Audio Layer 2 encoder (command line frontend)
    xmms-liveice - XMMS plugin that sends your audio to a shoutcast server


    ich installier jetzt mit apt-get install (toolame, twolame, libtwolame-dev & libtwolame0)

    mal schaun obs was bringt..

    EDIT: Es hat nichts gebracht. Es sind weiterhin Aussetzer im Stream bishin das der Player ganz abbricht.
     
  8. Inselkobi

    Inselkobi Benutzer

    AW: sc_trans: Problem

    Da muss ich Pegasus Recht geben. Ein aehnliches Problem hatten wir ebenfalls. (Debian 4.0 Etch auf 500 MHz mit 512 MB RAM)
    Die hatte sich dann erledigt nachdem wir den aktuellen Lame-Codec (3.97) installiert hatten und in der sc_trans folgende Zeile geaendert haben:

    geaendert in:
    Nach der Installation ein Neustart, dann sollte es klappen.
     
  9. Montague

    Montague Benutzer

    AW: sc_trans: Problem

    Ich "fahre" mit 1 also mit FAST im sc_trans.

    Ich versuchs mal mit dem neuesten Codec..
     
  10. Montague

    Montague Benutzer

    AW: sc_trans: Problem

    Bei der Installation vom Lame 3.97 gab er mir bei ./configure haufenweise Meldungen mit -no

    hier einige Ausschnitte, außer die mit Yes:

    checking minix/config.h usability... no
    checking minix/config.h presence... no
    checking for minix/config.h... no

    checking for g77... no
    checking for f77... no
    checking for xlf... no
    checking for frt... no
    checking for pgf77... no
    checking for fort77... no
    checking for fl32... no
    checking for af77... no
    checking for f90... no
    checking for xlf90... no
    checking for pgf90... no
    checking for epcf90... no
    checking for f95... no
    checking for fort... no
    checking for xlf95... no
    checking for ifc... no
    checking for efc... no
    checking for pgf95... no
    checking for lf95... no
    checking for gfortran... no
    checking whether we are using the GNU Fortran 77 compiler... no
    checking whether accepts -g... no

    checking if gcc supports -fno-rtti -fno-exceptions... no
    checking whether -lc should be explicitly linked in... no
    checking dmalloc.h usability... no
    checking dmalloc.h presence... no
    checking for dmalloc.h... no
    checking whether byte ordering is bigendian... no
    checking for special C compiler options needed for large files... no
    checking for _LARGE_FILES value needed for large files... no

    checking for ieee854_float80_t... no
    checking for ieee754_float64_t... no
    checking for ieee754_float32_t... no

    checking winsock2.h usability... no
    checking winsock2.h presence... no
    checking for winsock2.h... no
    checking for socket... yes
    checking termcap.h usability... no
    checking termcap.h presence... no
    checking for termcap.h... no
    checking ncurses/termcap.h usability... no
    checking ncurses/termcap.h presence... no
    checking for ncurses/termcap.h... no
    checking for initscr in -ltermcap... no
    checking for initscr in -lcurses... no
    checking for initscr in -lncurses... no
    checking for cos in -lm... yes
    checking for cos in -lffm... no
    checking for cos in -lcpml... no
    checking for sf_open_read in -lsndfile... no
    checking for gtk-config... no

    checking for GTK - version >= 1.2.0... no
    checking if mp3x is requested... no
    checking if mp3rtp is requested... no
    checking glibc mathinline bug... no
    checking use of VBR bitrate histogram... yes, simulated termcap
    checking for FLOAT8 as float... no
    checking for nasm... no
    checking for additional optimizations... no
    checking for debug options... no

    configure: creating ./config.status
    config.status: creating Makefile
    config.status: creating libmp3lame/Makefile
    config.status: creating libmp3lame/i386/Makefile
    config.status: creating frontend/Makefile
    config.status: creating mpglib/Makefile
    config.status: creating doc/Makefile
    config.status: creating doc/html/Makefile
    config.status: creating doc/man/Makefile
    config.status: creating include/Makefile
    config.status: creating Dll/Makefile
    config.status: creating misc/Makefile
    config.status: creating debian/Makefile
    config.status: creating dshow/Makefile
    config.status: creating ACM/Makefile
    config.status: creating ACM/ADbg/Makefile
    config.status: creating ACM/ddk/Makefile
    config.status: creating ACM/tinyxml/Makefile
    config.status: creating lame.spec
    config.status: creating mac/Makefile
    config.status: creating config.h
    config.status: executing depfiles commands


    Genau bei solchen Dingen, ist mit meinem Horizont von Linux schluss.
    Ich weiß, das da Abhängigkeiten nicht passen oder nicht vorhanden sind, aber... :confused:

    Ich korrigiere meine obrige Meldung mit sc_trans und der Einstellung 1-10.

    Grundsätzlich verwend ich 10 - aber eine 1 also mit bester Qualität, sind genauso Aussetzer.
     
  11. Pegasus

    Pegasus Benutzer

    AW: sc_trans: Problem

    Solange die Config angelegt wird (ist hier der Fall, sonst käme am Ende ein Error), ist alles ok. nach dem ./configure ein

    make && make install

    Wie man unter Debian Pakete baut, erklär ich jetzt nicht, zuviel Stress
     
  12. Montague

    Montague Benutzer

    AW: sc_trans: Problem

    Durch die Hilfe eines Freundes, ist nun der neue Lame Codec installiert.

    Trotzdem schreibt mir sc_trans
    <01/12/08@17:10:13> [TRANSCast] DNAS/posix v0.400-LAME (Mar 4 2003) starting up...


    posix v0.400-Lame (März 2003) - weiß nicht ob er jetzt den alten Codec verwendet.

    <01/12/08@17:10:13> Warning: input file samplerate is -1208007943 Hz, must be 44100! / bei jeder Datei!

    schreibt er mir auch trotz genauer Überprüfung der mp3 Datein

    Der Stream funktioniert mit einem Flashplayer, Media Player (trotz längerem Puffern), Real Player und mit WinAMP (bei mir aber nur auf einen Rechner im Studio).

    Ich denke das auch icecast mitschuld ist, da bei vielen Hörern Aussetzern bei 128kBit sind. Icecast hat wie oben angesprochen eben fast keine Verzögerung, somit puffert icecast den Stream nicht zwischen. Der Stream geht direkt an die Hörer weiter. Mit verminderter Bitrate gibt es sowieso keine Probleme. Wir hatten icecast1 im Jahr 1999 sehr professionell im Einsatz. Da hatten wir aber noch 24kBit Bitrate als Stream. (Es gab eben über 90% nur Hörer mit Modem :)

    Ich hab jetzt zusätzlich zu icecast, die neueste Version von Shoutcast am Server laufen. Shoutcast ist als Relay konfiguriert - ist bei icecast ein client.

    Bei shoutcast gibt es mit der obrig genannter Abspielsoftware überhaupt keine Probleme.

    Der dient nun als Ausweichstream - schlimmsten Falls als Stream, den die Hörer grundsätzlich abgreifen. Da ich dann bei icecast1 immer noch meine Funktionen habe die ich benötige.

    ...und ich bedanke mich bei 'Inselkobi' und vorallem bei 'Pegasus'.
    Es ist absolut nicht selbstverständlich, dass sich jemand Zeit nimmt, um eine - ja doch - fremde Person, eine Hilfleistung unbezahlt anzubieten.

    musikalische Grüße
     

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

Diese Seite empfehlen