Autor |
Nachricht |
ex-user
Gast
|
Verfasst am:
14.10.2007, 17:50 Videoschnitt Probleme - Hilfe |
|
Ich habe zwei Programme gefunden für "Ubuntu":
- Cinelerra
- LiVES
Bei LiVES bekomme ich die Meldung:
Is ieee1394, driver, and raw 1394 loaded?
Unten bei der Ausgabe steht dann:
Couldn't get 1394 handle.
Unter /dev/ gibt es den Ordner dv1394.
Jemand eine Ahnung woran es liegt und wie ich checken kann ob der Treiber für ieee1394 bzw. raw1394 installiert ist?
Bei Cinelerra bekomme ich gleich beim Start einen Fehler, mit dem ich gar nichts anfangen kann:
Hat jemand hierfür eine Lösung? Ich denke das es etwas mit 7.10 zu tun hat, weil unter 7.04 hatte ich den Fehler nicht!
Würde mich freuen wenn mir hier jemand weiter helfen könnte. Also wie schon zu lesen ist, es handelt sich um Ubuntu Gusty Gibbon 7.10!
Desktop: anderer
Version: 16.04
Hardware: Notebook
Architektur: 64Bit
|
|
|
|
Gast
|
Verfasst am:
14.10.2007, 19:34 (Kein Titel) |
|
lsmod | grep 1394
sollte dir geladene Treiber anzeigen.
Desktop: anderer
Version: 16.04
Hardware: Notebook
Architektur: 64Bit
|
|
|
|
ex-user
Gast
|
Verfasst am:
14.10.2007, 19:53 (Kein Titel) |
|
Kommt die Ausgabe:
ohci1394 36528 0
ieee1394 96312 2 sbp2,ohci1394
Desktop: anderer
Version: 16.04
Hardware: Notebook
Architektur: 64Bit
|
|
|
|
Webbutterfly
Administrator
Geschlecht:
Alter: 68
Anmeldungsdatum: 24.06.2006
Beiträge: 6917
Wohnort: Wien 23
|
Verfasst am:
14.10.2007, 20:30 (Kein Titel) |
|
Hello
..es steht ja dort was du machen sollst:
Before running Cinelerra to the following as root:
echo "0x7fffffff" > /proc/sys/kernel/shmmax
also
sudo echo "0x7fffffff" > /proc/sys/kernel/shmmax
...schon gemacht?
Weiters ist 7.10 noch RC... und soweit ich sehe kommen derzeit noch eine Menge Updates....
Desktop: Gnome-Shell 3.X
Version: 14.04 and 16.04
Hardware: Notebook
Architektur: 64Bit
_________________
|
|
|
|
Gast
|
Verfasst am:
14.10.2007, 22:25 (Kein Titel) |
|
« Webbutterfly » hat folgendes geschrieben:
sudo echo "0x7fffffff" > /proc/sys/kernel/shmmax
...schon gemacht?
sry aber das umlenken wird da trotzdem noch mit nomalen userrechten gemacht
echo "0x7fffffff" | sudo tee /proc/sys/kernel/shmmax
heisst glaub ich der richtige syntax
Desktop: anderer
Version: 16.04
Hardware: Notebook
Architektur: 64Bit
|
|
|
|
ex-user
Gast
|
Verfasst am:
15.10.2007, 01:07 (Kein Titel) |
|
sudo echo "0x7fffffff" > /proc/sys/kernel/shmmax
Das hatte ich gemacht, dass hatte nicht funktioniert.
echo "0x7fffffff" | sudo tee /proc/sys/kernel/shmmax
Das FUNKTIONIERT!!! DANKE!!!
Desktop: anderer
Version: 16.04
Hardware: Notebook
Architektur: 64Bit
|
|
|
|
Gast
|
Verfasst am:
15.10.2007, 02:07 (Kein Titel) |
|
datacop hat schon recht und gateway und butterfly sowieso auch...
">" markiert den Beginn eines neuen Befehls und somit gilt sudo nichtmehr für den Schreibprozess wos eigentlich gebraucht wird.
Abhilfe würde außerdem schaffen vorher sudo -i auszuführen.
Btw. danke für den Ersatz, darauf hab ich schon länger gewartet.
<-
Desktop: anderer
Version: 16.04
Hardware: Notebook
Architektur: 64Bit
|
|
|
|
ex-user
Gast
|
Verfasst am:
15.10.2007, 13:27 (Kein Titel) |
|
ich habe mir darüber gestern noch den kopf, fast, zerbrochen.
es liegt ja wohl am | das sudo hier nichts bewirkt, wenn ich das richtig erkannt habe?
NACHTRAG: oh jetzt hab ich erst kapiert was du meinst, es liegt also an den " "??? oder eh an der "weiterleitung" oder wie sich das jetzt nennt, hab ich schon wieder vergessen
worauf bezieht sich:
Zitat: tw. danke für den Ersatz, darauf hab ich schon länger gewartet.
????
Desktop: anderer
Version: 16.04
Hardware: Notebook
Architektur: 64Bit
|
|
|
|
Gast
|
Verfasst am:
15.10.2007, 14:35 (Kein Titel) |
|
In einem Skript ist es schwer für einen Befehl rootrechte zu erlangen ohne das ganze mit solchen auszuführen.
ZB bei dem Befehl cat test > /etc/test wird nichts passieren, weil die Rechte nicht reichen.
sudo cat test > /etc/test geht auch nciht, weil nur mit rootrechten eingelesen wird, der Schreibvorgang aber ein eigener Befehl ist, auf den sudo nicht mehr wirkt.
cat test sudo > /etc/test geht auch nicht, macht eigentlich garnichts.
Deshalb braucht man in einem Skript die oben genannte Lösung wenn man verhindern will, dass das ganze Skript mit rootrechten ausgeführt wird.
Funktionieren tut das ganze trotzdem nicht...
Das ist der Workaround für das Soundproblem von Enemy Territory und müsste vor dem Spiel ausgeführt werden. Es ginge auch Systemweit beim Booten, ich würds aber auch gern so hinbringen.
echo "et.x86 0 0 direct" > /proc/asound/card0/pcm0p/oss ## ist der eigentliche Befehl
echo "et.x86 0 0 direct" | gksudo tee /proc/asound/card0/pcm0p/oss ## Abwandlung von mir um das ganze vor der binary auszuführen.
Passwortabfrage kommt, aber Effekt hats keinen. Hat dazu jemand eine Idee? Ich bin mir sicher ich überseh nur was total offensichtliches.
Danke
<-
Desktop: anderer
Version: 16.04
Hardware: Notebook
Architektur: 64Bit
|
|
|
|
|