Ubuntu-Austria Foren-Übersicht
Portal  •  Forum  •  Profil  •  Suchen   •  Registrieren  •  Einloggen, um private Nachrichten zu lesen  •  Login   

 Videoschnitt Probleme - Hilfe

Neues Thema eröffnenNeue Antwort erstellen
Autor Nachricht
ex-user
Gast










BeitragVerfasst am: 14.10.2007, 17:50    Videoschnitt Probleme - Hilfe Antworten mit ZitatNach oben

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
Online    
Gast











BeitragVerfasst am: 14.10.2007, 19:34    (Kein Titel) Antworten mit ZitatNach oben

lsmod | grep 1394

sollte dir geladene Treiber anzeigen.


Desktop: anderer

Version: 16.04

Hardware: Notebook

Architektur: 64Bit
Online    
ex-user
Gast










BeitragVerfasst am: 14.10.2007, 19:53    (Kein Titel) Antworten mit ZitatNach oben

Kommt die Ausgabe:

ohci1394               36528  0
ieee1394               96312  2 sbp2,ohci1394


Desktop: anderer

Version: 16.04

Hardware: Notebook

Architektur: 64Bit
Online    
Webbutterfly
Administrator



Geschlecht:
Alter: 64
Anmeldungsdatum: 24.06.2006
Beiträge: 6917
Wohnort: Wien 23


austria.gif

BeitragVerfasst am: 14.10.2007, 20:30    (Kein Titel) Antworten mit ZitatNach oben

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

_________________

European Open Source Center
www.webbutterfly.com

OfflineBenutzer-Profile anzeigenPrivate Nachricht sendenWebsite dieses Benutzers besuchen    
Gast











BeitragVerfasst am: 14.10.2007, 22:25    (Kein Titel) Antworten mit ZitatNach oben

« 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
Online    
ex-user
Gast










BeitragVerfasst am: 15.10.2007, 01:07    (Kein Titel) Antworten mit ZitatNach oben

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!!! Very Happy


Desktop: anderer

Version: 16.04

Hardware: Notebook

Architektur: 64Bit
Online    
Gast











BeitragVerfasst am: 15.10.2007, 02:07    (Kein Titel) Antworten mit ZitatNach oben

datacop hat schon recht und gateway und butterfly sowieso auch... wink
">" 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
Online    
ex-user
Gast










BeitragVerfasst am: 15.10.2007, 13:27    (Kein Titel) Antworten mit ZitatNach oben

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 Smile


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
Online    
Gast











BeitragVerfasst am: 15.10.2007, 14:35    (Kein Titel) Antworten mit ZitatNach oben

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
Online    
Beiträge der letzten Zeit anzeigen:      
Neues Thema eröffnenNeue Antwort erstellen


 Gehe zu:   



Berechtigungen anzeigen


Forensicherheit

1008050212024 Angriffe abgewehrt

Powered by Orion based on phpBB © 2001, 2002 phpBB Group
CBACK Orion Style based on FI Theme
Alle Zeiten sind GMT + 2 Stunden



[ Page generation time: 0.7833s (PHP: 96% - SQL: 4%) | SQL queries: 65 | GZIP enabled | Debug off ]