webForumDet fria alternativet

Schemaläggning med at - fungerar inte som jag vill

Linux & BSD

4 svar · 356 visningar · startad av dho

Medlem sedan aug. 20022 027 inlägg
Frågan#1

Hej,

Har under kvällen donat med ett shellscript som ska spara streamad radio till en wav-fil för att sedan konvertera den till antingen en mp3- eller ogg-fil. Scriptet fungerar precis som jag vill när jag antingen kör det direkt eller via cron. Problemet är att det vägrar att fungera om jag istället schemalägger den via atd. I felmeddelandet som jag får så ser jag att scriptet körs, men det verkar som om den kör alla tre kommandon direkt efter varandra istället för att vänta till ett kommando har kört färdigt innan den börjar på nästa. Jag har något svagt minne av att det inte fungerar att använda semikolon i scriptfiler tillsammans med atd, men jag hittar ingen information som kan styrka det. Är det någon som har något tips på hur jag kan lösa problemet? :)

Scriptfilen ifråga:

#!/bin/sh

mplayer -playlist /home/user/scripts/playlist.txt -ao pcm -aofile /home/user/radiostream.wav -vc dummy -vo null; lame -m s -q 2 -b 192 /home/user/radiostream.wav -o /home/user/radiostream.mp3; rm /home/user/radiostream.wav;

Felmeddelande, något avkortat:

Cache size set to 1024 KBytes
Connected to server: sr-wm.qbrick.com
Cache fill:  0,00% (0 bytes)

Exiting... (End of file)
Could not find "/home/user/radiostream.wav".
rm: kan inte ta bort "/home/user/radiostream.wav": Filen eller katalogen finns inte
Medlem sedan juni 20014 290 inlägg
#2

Nej, det är ingen skillnad hur sh behandlar ; tecknen.

Det som kan vara skillnad är ur miljön ser ut, vad PATH variabeln inehåller ..., prova att sätt PATH i skriptet till det du har när du är inloggad.

Sedan förstår jag inte vittsen med att lägga alla kommandom på en och samma rad, det är samma sak om du lägger dom på olika rader, nästa rad körs när kommandot på föregående rad avslutats.

Jag skulle gjort så här:

#!/bin/sh

mplayer -playlist /home/user/scripts/playlist.txt -ao pcm -aofile /home/user/radiostream.wav -vc dummy -vo null
lame -m s -q 2 -b 192 /home/user/radiostream.wav -o /home/user/radiostream.mp3
rm -f /home/user/radiostream.wav

Det blir mera läsligt då.

Medlem sedan aug. 20022 027 inlägg
#3

Jag har prövat att lägga till absoluta sökvägar till alla kommandon nu men jag får samma fel som tidigare. så det borde väl inte kunna bero på skillnader i PATH-variabeln då? Prövade även att lägga alla kommandon på varsin rad med samma resultat. Som tidigare så fungerar det både att köra scriptet direkt och via cron.

Om man ser till felmeddelandet i första posten så ser det ut som om mplayer slutar köra istället för att börja fylla sin cache. Rimligtvis så borde ju mplayer fortsätta köra tills man dödar den processen, men istället så verkar det som om resterande kommandon körs istället. Tar tacksamt emot fler tips. :)

Medlem sedan juni 20014 290 inlägg
#4

Om du bryter ner problemet och bara kör mplayer går mplayer klart då?

Du kan också hänga på flaggan -x på scriptet ( börja med: #!/bin/sh -x ) då kan du se hur scriptet körs och på så sätt se vilket program som genererar vilket felmeddelande.

Det är lätt gjort att man tror att ett visst meddelande tillhör ett visst rad om man inte skriver ut raderna.

Det kan också vara ett rättighetsfel att den inte kan skriva i /hom/user är det någon skillnad om du lägger filerna i /tmp där alla har rätt att skriva? (är det som samma anvädare du testar hela tiden?)

Medlem sedan aug. 20022 027 inlägg
#5

GunnarD skrev:

Om du bryter ner problemet och bara kör mplayer går mplayer klart då?

Nej, jag får samma felmeddelande även om jag enbart kör mplayer.

GunnarD skrev:

Du kan också hänga på flaggan -x på scriptet ( börja med: #!/bin/sh -x ) då kan du se hur scriptet körs och på så sätt se vilket program som genererar vilket felmeddelande.

Det är lätt gjort att man tror att ett visst meddelande tillhör ett visst rad om man inte skriver ut raderna.

Bra tips. :) Jag får då ut följande felmeddelande. Det verkar nästan som om det händer någonting när det är dags för mplayer att fylla sin cache, någonting som tar runt 8-10 sekunder. Vad kan till exempel Exiting... (End of file) betyda? Mplayer spottar ut sig lite felmeddelanden också, som could not connect to socket och unknown object. Jag undrar om det kan ha något med det att göra, men det är ju i sådana fall konstigt att det bara blir fel när jag schemalägger via at.

+ /usr/bin/mplayer -playlist /home/user/scripts/playlist.txt -ao pcm -aofile /tmp/radiostream.wav -vc dummy -vo null
MPlayer 1.0pre6-3.3.5 (C) 2000-2004 MPlayer Team
CPU: Advanced Micro Devices Athlon Thunderbird (Family: 6, Stepping: 4)
Detected cache-line size is 64 bytes
CPUflags:  MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 0 SSE2: 0
Compiled for Debian.

Terminal type `unknown' is not defined.
Opening joystick device /dev/input/js0
Setting up LIRC support...
mplayer: could not connect to socket
mplayer: Filen eller katalogen finns inte
Failed to open LIRC support.
You will not be able to use your remote control.
Playing mms://sr-wm.qbrick.com/02038_p3-wm-high.
Resolving sr-wm.qbrick.com for AF_INET...
Connecting to server sr-wm.qbrick.com[195.149.158.119]:1755 ...
connected
unknown object
unknown object
file object, packet length = 4490 (4490)
unknown object
stream object, stream id: 1
stream object, stream id: 2
unknown object
unknown object
data object
mmst packet_length = 4490
Cache size set to 1024 KBytes
Connected to server: sr-wm.qbrick.com
^MCache fill:  0,00% (0 bytes)

Exiting... (End of file)
+ /usr/bin/lame -m s -q 2 -b 192 /tmp/radiostream.wav -o /home/user/radiostream.mp3
Could not find "/tmp/radiostream.wav".
+ /bin/rm /tmp/radiostream.wav
/bin/rm: kan inte ta bort "/tmp/radiostream.wav": Filen eller katalogen finns inte

GunnarD skrev:

Det kan också vara ett rättighetsfel att den inte kan skriva i /hom/user är det någon skillnad om du lägger filerna i /tmp där alla har rätt att skriva? (är det som samma anvädare du testar hela tiden?)

Samma här, att spara wav-filen i /tmp istället gjorde inte någon skillnad tyvärr. Det är samma användare som jag testar med hela tiden.

256 ms totalt · 3 externa anrop · v20260731065814-full.aa8cfc83
121 ms — deklarationer (db)
0 ms — hämta statistik (cache)
132 ms — hämta tråd, inlägg och bilagor (db)