Näytä kirjoitukset

Tässä osiossa voit tarkastella kaikkia tämän jäsenen viestejä. Huomaa, että näet viestit vain niiltä alueilta, joihin sinulla on pääsy.


Viestit - tikola

Sivuja: 1 ... 8 9 [10] 11
181

ProjectX:n nykyinen CVS-versio, jota kannattaa muutenkin käyttää, osaa tarvittaessa muuntaa DVB-tekstityksen VobSub-muotoon, jota Avidemux varmaankin ymmärtää. Toinen vaihtoehto on yllä mainittu pxsup2dast+spumux, jos Avidemux lukee SPU-tekstitykset MPEG-PS-tiedostosta.



Tuossa VobSub jutussa on itua. Testaan huomenna. Periaatteessa siis kaksi ongelmaa on enää päällä:

1) Avidemux ei ymmärtänyt ainakaan ensimmäisillä kokeiluilla ProjectX:n tuottaman subtitles tiedoston päälle. Se oli silloin SRT ja nyt huomenissa yritän tuon VobSubin kanssa

2) Alkuperäinen ongelma on myös edelleen päällä ja kaikki sen jälkeen on ollut kiertotietä ensimmäiseen. Miksi Avidemux ymmärtää helposto VDR:n tuottaman .ts:n päälle, mutta kun suunnilleen sama kama tulee Topfieldistä ulos (transport stream sielläkin käsittääkseni) se ei sen päälle ymmärrä? Minusta siinä on kaksi vaihtoehtoa:
  • Joko formaatti ei ole oikeasti sama
  • tai sitten se alkuperäinen juttu, eli tiedoston tunnistuminen vääräksi tiedostotyypiksi hajottaa homman

Mutta jatketaan tästä huomenna,

timo

182
Nyt näyttäisi että ensimmäinen toimiva ketju on:

- ProjectX, jolla demuxaan topfieldin .rec tiedoston noihin erillisiin tiedostoihin.
- Topfieldin DVDn poltto-ohjeiden mukaisesti jatketaan DVDAuthorGUIlla ja tekaistaan em. datasta DVD valmiit tiedostot
- Acidripillä käännetään em. DVD tiedostot yhdeksi aviksi.
- Avidemuxilla hoidetaan mainosten yms. roskan leikkuu
- ja jollain vielä tuntemattomalla ohjelmalla runtataan lopulliset avit DVD:lle jotta mummo osaa sen käyttää

Onnistuu noinkin, mutta verrattuna vdr pohjaisten nauhoitusten yhteen Avidemux ajoon prosessi on aika mittava. Oikotie tyssäsi siihen että ainakaan vähällä en saanut Avidemuxia ymmärtämään projectX:n subtitles tiedostoa.

timo

183
Tilanne on seuraava. Minulla on Topfield ja VDR pohjaisia TV tallenteita, jotka on tarkoitus siirtää DVD:lle (Ruotsin prinsessahäitä mummolle)

VDR pohjaiset käyttäytyvät siististi ja saan avidemuxilla (ja projectX:llä) tehtyä kaikki kaipaamani temput. Topfieldin digiboksilta tuomani tallenteet kaatavat avidemuxin (avaaminen ja indeksointi ei onnistu). Erona tiedostojen välillä on, että Linux peräisissä tiedostoissa tiedoston tyypin kohdalla lukee "MPEG-2 transpport stream" ja Topfield pohjaisissa lukee "Message catalogue" Tiedoston pääte on molemmissa sama ja mencoder skriptini muuntaa molemmat aviksi mukisematta. Ongelma on lähinnä se, että minun pitäisi askarrella tekstit kiinni kuvaan, koska mummon kielitaito on rajoittunut. Siihen tuo avidemux tarvittaisiin. Oletus on siis se, että pelkkä topfieldin .rec tiedostopääteen muuttaminen .ts:ksi ei muuttanut tuuota tiedostotyyppiä ja siihen avidemux kyykähtää.

Miten vaihtaa siis tiedostotyyppi vai onko se jotain jonka kone päättää puolestani päätteen perusteella.

timo

184
Periaatteessa tuossa ajatuksessa voisi olla tolkkua. Toisaalta sillä vain korjataan vika, mutta ei paikanneta syytä. Ennen tuota ratkaisumallia käytin hieman toisenlaisia komentoja ja niissä onglema oli ettei etukäteen ole ihan varma kumpi levy milloinkin oli mukaan lähtenyt. Oletan että tämä liittyy jotenkin SATA levyjen vaihtelevaan käynnistysjärjestykseen. Tuolla nykyisellä komentorimpsulla ei tämä vaikuta mitään, koska kumminkin kasaan sen aina uusiksi. Siis ideasi nähdäkseni voisi hyvinkin toimia. Jatkan kumminkin ensin varsinaisen syyn metsästämistä ja sitten kun kyllästyn tuon rimpsun toistamiseen alan pohtia ideaasi tarkemmin.

Kiitoksia vinkistä,

Timo

186

Lainaus
Tuleekohan ongelma toistumaan sitten joskus kun seuraavan kerran ajastettu levyntarkastus tarvitaan?

Vain jos levyllä on taas jotain niin pahasti rikki.


Siis minun "few bad sectors" voi olla semmoinen asia, joka aiheuttaa ongelmia seuraavan kerran sitten puolen vuoden päästä. Käyttöä se ei ole vielä haitannut mitenkään muuten.

timo

ps. Piti vain vetäistä kuumeisen lapsen kanssa pienet päiväunet tuon levyntarkistuksen ja buuttauksen välillä - siitä pieni viive tänne foorumille Buuttaaminen kun on työlästä kahdesta syystä:

- RAID 1 pakka ei herää koskaan buutin jälkeen vaan joudun tekemään sen aina käsin. Tästä on oma threadi jo olemassa: http://forum.ubuntu-fi.org/index.php?topic=28006.msg220053#msg220053
- Ja koska kone on minulle fileserverinä ilman näyttöä ja käytän sitä vain VNC:llä siinä on sellainen ominaisuus ettei se suostu buuttaamaan itseään loppuun saakka ellei näyttö ole kiinni. Tästä en ole vielä omaa threadia saanut aikaiseksi.

Joudun siis kyykkimään koneen taakse ja liittämään näytön ja tekemään muitakin jippoja ennen kuin kaikki on aina buutissa ennallaan niin siksi buuttaamista aina vältellään ja venytetään mahdollisimman pitkään - ja nyt päiväunet ajoivat edelle.

Lisäksi päivityksessä Kaffeine pohjainen tallennusdigiboxi viritys laukesi, mutta se korjautui foorumin ohjeilla palaamalla vanhaan tuttuun ja toimivaan Kaffeine 0.8.7 versioon sen uuden 9.10 Ubuntun tarjoaman 1.0***'version tilalle

187
Ei tee enää samaa vaan nyt buuttaa normaalisti ja recording hakemistoni on mounttautuneena kuten pitääkin. Oliko tässä siis kyse siitä että syystä tai toisesta levyntarkastus ei mennyt buutissa läpi ja nyt kun levyntarkastus ajettiin "väkisin" se tuli tarkastettua ja näinollen kaatuvaa tarkastusta buutissa ei enää tehdä.

Tuleekohan ongelma toistumaan sitten joskus kun seuraavan kerran ajastettu levyntarkastus tarvitaan?

timo

188
tikola@serveri:~/recording$ sudo fsck.ext3 /dev/sdb1
e2fsck 1.41.9 (22-Aug-2009)
recording has gone 190 days without being checked, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
recording: 27978/91578368 files (7.2% non-contiguous), 148655694/366284000 blocks


Äkkipäätä tulkitsisin ettei mitään fataalia ole levyssä?

timo

189
9.10 versiossa on saavuttettu tila, jossa edelleenkin buutissa md0 laite katoaa ja tilalle tulee md_d0 laite. Välillä tuo md_d0 on ihan täydellinen kahden levyn raid-1 pakka ja välillä se toimii vain toisella levyllä. Myös mounttauksen joudun tekemään käsin, koska en ole vielä keksinyt tapaa raid-1 pakan pysyvään mounttaukseen.

Jatkan siis jokaisen buutin jälkeen seuraavalla komentorimpsulla, jolla palautan homman haluamalleni tolalle

cat /proc/mdstat
sudo mdadm --stop /dev/md_d0
sudo mdadm /dev/md0 --assemble --force --add /dev/sdd1 /dev/sdc1
sudo mount /dev/md0 /home/tikola/data


Tämä tapaus voidaan siis pitää ratkaistuna siinä mielessä että toimiva kiertotie on keksitty. Lopullista hyvä ja oikeaa ratkaisua ei vielä ole.


timo


190
Tällä aloittelevan linux harrastajan tiellä on monta mutkaa. Versiopäivitys kannattaa ehdottomasti ja se tuo joka kerta korjauksia ongelmiin. Toisaalta lähes joka versiopäivityksessä jokin aiemmin hyvin toiminut asia rupeaa reistaamaan. Nyt 9.04 -> 9.10 päivtyksessä vaivaa rupesi tuottamaan yksi levy. Kyseessä on ihan perus SATA levy, jota olen käyttänyt TV tallennuspaikkana. Levy on normaali ext3 ja se on mountattu omaksi hakemistoksi kotihakemistooni. 9.04 maailmassa kaikki toimi kuin junan vessa ja buutin jälkeen kyseinen hakemisto näkyi datoineen. Nyt 9.10 versiossa Disk Utility kertoo levyllä olevan vähäinen määrä bad sectoreita. Tämä ilmeisestikkin poikii aina buutissa levyn tarkistuksen. Tuo tarkistus ei mene koskaan läpi ja kone vilauttaa ruudulla, jotan aiheeseen liittyvää. Lopputulost prosessista on että mountausta ei buutissa tapahdu ja jos yritän tehdä sen käsin saan vastauksen: device already mounted or mount point busy. Mountattu se ei varmasti ole koska hakemisto on täydellisen tyhjä.

Jos buutin aikana kun tarkastus alkaa painan esciä (esc to skip test) lopputulos on täydellisesti mounttautunut levy ja hakemisto jota pystyn käyttämään kuten ennenkin.

Siis jotain siinä levyssä nyt on jota Ubuntu ryhtyy skannaamaan ja riippuen annanko skannauksen mennä läpi (kaatunee omia aikojaan, kun prosentti on aina nolla) vai katkaisenko sen tulos on hakemiston mounttauksen kannalta erilainen.

Logeista en ole vielä osannut kaivaa mitään järjellistä aiheeseen liittyvää.

timo

ps. Tämän versiopäivityksen positiivista antia oli se, että ääkköset kulkevat nyt läpi näppäimistöltä VNC:n kautta Ubuntulle.

191
Ja buutti hukkaa sen uudelleen ja tuo em. rimpsu pitaa toistaa jokaisen buuttauksen jalkeen. Rakentavia ideoita miten sen saisi pysymaan paalla kaivataan.

timo

192
Nyt se on sitten ratkaistu.

Toinen levy oli minulle tuntemattomasta syystä päätynyt laitteeksi md_d0 varsinaisen raid pakkani ollessa md0. Toisin sanoen minulle oli ilmestynyt uusi md laite ja se toinen levy oli luiskahtanut sinne. Tiivistäen kaikista komennoista oikeasti tarvitut olivat.

more /proc/mdstat - tämä paljasti mitä kaikkia md laitteita minulla löytyy

sudo mdadm --stop  /dev/md_d0 - tällä pysäytettiin väärä laite

mdadm /dev/md0 -f -a /dev/sdd1 - tällä tuupattin se hukassa ollut levy kiinni oikeaan pakkaan

Ja toistaiseksi kaikki toimii - saa nähdä mitä buutti tälle tekee...

timo

193
Laitealue / Vs: RAID-1 ei herännyt buutin jälkeen
« : 20.07.09 - klo:12.11 »
Jatketaan sen verran että pari buuttia ja sekalaisia mdadm tarjottuani olen päässyt tilaan, jossa md0 laite on olemassa ja toimii....tosin vain toisella levyllä. Levy joka ei ole mukana näyttäisi vaihtelevan, eli vuoronperään se superblock puuttuu jommasta kummasta limpusta.

Päästäänkö tästä siis siihen, minkä jostain keskustelusta luin, että koneessani SATA levyt buuttaavat hieman eritahtiin ja siten laitenimet menevät sekaisin....josta seuraa superblock ongelma.




timo

194
Kasasin eilen RAID-1 pakan ja kopion sinne datoja. Kaikki meni hienosti ja homma toimi. Aamulla buuttasin koneen ja katso raid pakkaa ei näkynytkään missään. No sitten googlella hakemaan neuvoja ja tähän on päästy.

1) Molemmat levyt ovat kunnossa ja mdadm -E antaa molemmista lupaavaa järkevää tietoa - correct lukee kaikkialla, joten oletan asioiden olevan kunnossa.

tikola@serveri:~$ sudo mdadm -E /dev/sdc1
/dev/sdc1:
          Magic : a92b4efc
        Version : 00.90.00
           UUID : 925e226b:c1661175:5c658924:daf7db08 (local to host serveri)
  Creation Time : Sun Jul 19 16:29:53 2009
     Raid Level : raid1
  Used Dev Size : 976759936 (931.51 GiB 1000.20 GB)
     Array Size : 976759936 (931.51 GiB 1000.20 GB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 0

    Update Time : Mon Jul 20 09:44:54 2009
          State : clean
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0
       Checksum : 34c46d6 - correct
         Events : 8


      Number   Major   Minor   RaidDevice State
this     0       8       33        0      active sync   /dev/sdc1

   0     0       8       33        0      active sync   /dev/sdc1
   1     1       8       49        1      active sync   /dev/sdd1



2) md0 laitetta ei ole, eli pakka ei ole käynnistynyt

tikola@serveri:~$ sudo mdadm --query --detail /dev/md0
mdadm: md device /dev/md0 does not appear to be active.


3) Syylliseksi epäilen "superblokin" puuttumista toisesta pakan levystä.

tikola@serveri:~$ sudo mdadm -A /dev/md0 /dev/sdc1
mdadm: cannot open device /dev/sdc1: Device or resource busy
mdadm: /dev/sdc1 has no superblock - assembly aborted


Kaikki hyvät ajatukset otetaan vastaan - vaikka ei se levyjen formatointi ja pakan uudelleenkasaus ole mikään mahdottomuus sekään, mutta jos tuon saisi heräteltyä niin hyvä - ja samalla kun saisi idean miten pitää se toimivana seuraavan buutin yli niin kaikki olisi taas hienosti.


timo

195
Ensin smb.conf kuten veekoo sanoi

**************
dos charset = CP850
unix charset = UTF-8
display charset = LOCALE
*******************

Ja sitten perään komento

"convmv -f iso8859-1 -t utf-8 -r --notest *"

ja voila - kaikki toimii halutulla tavalla, mukaanlukien hakemistojen nimet, jotka ensin hieman arveluttivat.

conmv man sivulla puhuttiin että nyt lopultakin samba 3 osaa utf-8 koodatut nimet. Olisiko siis alkuperäinen ongelma ollut se että olen kasannut oman samban ennen versiota 3 ja silloin aikanaan noita kikkailuja tehtiin. Uudessa versiossa kuten veekoo totesi ei näköjään tarvitse tehdä mitään vaan oletusarvoille varustettu smb.conf kelpaa.


timo

ps, Nyt sitten vielä toinen ubuntu, joka yrittää liittyä samaan samba jakoon näkee nauravia naamoja ja kommentoi dolpinissa "invalid encoding" - onneksi tässä on jotain muitakin harrastuksia välissä ettei ihan jokapäivä tarvitse ratkoa näitä encoding asioita eri koneilla.

196
Ääni minulta tälle viimeisimmälle ratkaisulle. Muutin smb.confin tuon mukaiseksi ja uusi ääkkösin varustettu tiedosto näkyi erinomaisesti sekä windowsissa samban takana että ubuntussa paikallisesti ääkkösin. Tuollaiset säilytä kaikki oletusarvoilla ratkaisut ovat aina niitä kaikkein parhaita ratkaisuja. Tosin  väitän että kun muutama vuosi sitten konffasin mediapalvelimen pystyyn silloisilla oletusarvoilla homma ei pelannut. Taisi olla Ubuntu 6.xx aikaa.

Nyt siis seuraavaksi alan opetella tuota convmv komennon käyttöä ja kerään rohkeuteni kokoon etten tule tehneeksi mitään peruutamatonta.



timo

197
Kiitoksia

Loistavat ohjeet - kun vielä lisäsin tuohon sen että terminaalista vaihdoin merkistön enkodauksen kaikkien noiden em. vaiheiden jälkeen ISO8859-1:ksi niin johan alkoivat ääkkösetkin näkyä komentorivillä.

Olen törmännyt joskus aiemminkin tuohon UTF-16/UTF-8 selitykseen windowsin ja ubuntun välissä. Jotenkin tuntuisi että lopullinen ratkaisu saadaan sinä päivänä kun Ubuntu alkaa käyttää UTF-16 merkistökoodausta. Näin maallikon näkökulmasta siirtymä nykyisestä UTF-8 merkistöstä samaan UTF-16 merkistöön kuin windows käyttää tuntuisi loogiselta kehitysaskeleelta. Siis korvataan nykyinen merkistö saman merkistön 16 bittisellä versiolla...toki sinä päivän windows varmaan on ehtinyt jo 32 bittiseen versioon tai keksinyt jotain ihan muuta.

Mitenkäs Ubuntun merkistö muutetaan pysyvästi, kuten johnsmith tuossa sivulauseessa mainitsi?



timo

198
Samba ja ääkkösongelma nyt seuraavasta näkökulmasta (olen koettanut hakea mutten ole tähän omaan tilanteeseeni löytänyt ratkaisua):

Ubuntu koneeni 9.04 hoitelee mediaserverin virkaa kotona. Siitä on tehty ulos jako samballa, josta sitten eri koneet soittelevat muusiikkia videoita tms.

smb.conf tiedostossa ääkköset on hoidettu seuraavalla tavalla:
dos charset = CP350
unix charset = ISO8859-1
display charset = ISO8859-1

Käytännössä tämän myötä verkon muut koneet (windows) näkevät ääkköset ongelmitta ja osaavat tuoda sinne ääkkösiä sisältäviä tiedostoja.

Nyt kun haluaisin ottaa backupin ubuntusta suoraan irtokovalevylle törmään neliö-kysymysmerkki yhdistelmiin. Käytännössä siis windows koneet näkevät ääkköset samban läpi hyvin, mutta ubuntu itsessään ei niitä näe. Tästä seuraa se, että backup ei onnistu koska merkistö sekoaa jne.

Olen tähän mennessä yrittänyt hakea ratkaisua muuttamalla esim. terminaalin merkkikoodausta ylävalikosta samaksi kuin tuossa smb.confissa käytetyt jne. mutta toistaiseksi vailla menestystä.

Mitenkäs tämä pitäisi hoitaa siten että samban kautta tulevat windows koneet ja omia hakemistojaan kurkkiva Ubuntu näkisivät ääkköset samoin ja oikein.


timo

ps. Ja ääkköset pois tiedostonnimistä ei ole ratkaisu minullekkaan vaikka sitä toki mahdollisuuksien mukaan toteutan. Haluan Itunesilla kuunneella Yö yhteyeen kappaletta Särkynyt Enkeli ja antaa Itunesin järjestellä hakemistot sen mukaan. En siis halua kuunnella Yo yhtyettä - ainakaan olettaen Olli Lindholmin laulavan.





199
no niin "sudo make unistall" siinä hakemistossa jossa lähdekoodi oli puri xine-lib 1.1.15:sta. Mutta altapa löytyy paria pykälää vanhampi versio 1.1.11, joka on käännetty joskus muinoin ja jonka lähdekoodihakemistosta minulla ei ole aavistustakaan. Siis missäs nyt voisi komentaa saman vai voiko missään?


timo

200
Eihän tuollaisia ohjeita ole tietenkään tullut luettua ja noudatettuaa vaan sokeasti rivi riviltä kopioiden xine-libin kääntö ohjeita. Tässä tapauksessa ./configurea on käytetty, joten pitänee siis lähteä hakemaan ratkaisua make uninstall tieltä - kun sen saan tehtyä lupaan pyhästi ikinä olevani kääntämättä xine-libiä

timo

Sivuja: 1 ... 8 9 [10] 11