Dilog DT-550PVR - felsökningstråd för USB

Jag har upptäckt att om man tar backup av sina inspelningar via USB på DT550, är det inte alltid överföringen fungerar som den ska.

Även om inspelningen fungerar helt och hållet i boxen, och är avkodad, så förlorar man data i överföringen till datorn. Om man sedan för över den "nya" filen från datorn till boxen, så fungerar den inte i boxen heller. Alltså kan man inte ta backup på sina inspelningar så som är avsikten med denna anslutning.

Efter mycket irritation och felsökning har jag äntligen lyckats avgöra vad som händer. Vid överföring via USB till datorn kan boxen blanda ihop flera inspelningar, även borttagna sådana. Det yttrar sig genom att filstorleken är den som du förväntat dig, men vid analys i t.ex ProjectX så ser man att där finns data från andra kanaler och krypterade paket som ännu inte avkodats. Kollar man just på dessa istället för den förstörda dataström man egentligen ville ha, så ser man att det är från kanaler som ligger på andra muxar, och program som inte sändes vid samma tid.

Denna ihopblandning sker inte i boxen när man bara spelar upp materialet utan uppstår endast vid överföring via USB.

Jag har alltså isolerad vad som händer men inte hur eller varför felet uppstår. Jag har rapporterat buggen till Dilog men jag hoppas kunna få hjälp av tekniskt kunniga entusiaster här på forumet för att bekräfta att detta händer på fler än min box och försöka isolera varför felet uppstår så att Dilog lättare kan rätta till det om det skulle behövas.

Det är för felsökningssyfte lämpligt att använda inspelningar från gratiskanalerna som inte är krypterade, för att se om det dyker upp krypterade paket i överföringarna, och lära sig vilka ström-PID denna kanal använder för att identifiera främmande paket. När du hittar främmande paket som INTE är krypterade, låt ProjectX söka på bara dessa främmande strömmar och se vad du får ut - förmodligen kommer du att känna igen det som en del från någon annan av dina inspelningar.

Jag har upptäckt att om man tar backup av sina inspelningar via USB på DT550, är det inte alltid överföringen fungerar som den ska.

Även om inspelningen fungerar helt och hållet i boxen, och är avkodad, så förlorar man data i överföringen till datorn. Om man sedan för över den "nya" filen från datorn till boxen, så fungerar den inte i boxen heller. Alltså kan man inte ta backup på sina inspelningar så som är avsikten med denna anslutning.

Efter mycket irritation och felsökning har jag äntligen lyckats avgöra vad som händer. Vid överföring via USB till datorn kan boxen blanda ihop flera inspelningar, även borttagna sådana. Det yttrar sig genom att filstorleken är den som du förväntat dig, men vid analys i t.ex ProjectX så ser man att där finns data från andra kanaler och krypterade paket som ännu inte avkodats. Kollar man just på dessa istället för den förstörda dataström man egentligen ville ha, så ser man att det är från kanaler som ligger på andra muxar, och program som inte sändes vid samma tid.

Denna ihopblandning sker inte i boxen när man bara spelar upp materialet utan uppstår endast vid överföring via USB.

Jag har alltså isolerad vad som händer men inte hur eller varför felet uppstår. Jag har rapporterat buggen till Dilog men jag hoppas kunna få hjälp av tekniskt kunniga entusiaster här på forumet för att bekräfta att detta händer på fler än min box och försöka isolera varför felet uppstår så att Dilog lättare kan rätta till det om det skulle behövas.

Det är för felsökningssyfte lämpligt att använda inspelningar från gratiskanalerna som inte är krypterade, för att se om det dyker upp krypterade paket i överföringarna, och lära sig vilka ström-PID denna kanal använder för att identifiera främmande paket. När du hittar främmande paket som INTE är krypterade, låt ProjectX söka på bara dessa främmande strömmar och se vad du får ut - förmodligen kommer du att känna igen det som en del från någon annan av dina inspelningar.

<{POST_SNAPBACK}>

Jag kan bekräfta att jag har haft detta eller liknande problem. Vid överföring via USB Downloader var filerna inte användbara längre trots att de fungerade i boxen. Körde man tillbaka filen till boxen så fungerade den inte heller i boxen. Originalfilen som fanns kvar i boxen under ett annat namn fortsatte att fungera. Det var samma problem både för program inspelade från de fria kanalerna som från betalkanalerna som före överföring avkodades i boxen. Jag har aldrig provat detta med icke avkodade inspelningar eftersom det inte finns någon poäng med det.

Problemet löstes med byte av box. Det krävdes 2 byten eftersom den ena boxen blev skadad vid transport till mig. Ros till Dilogs (Martin) och Webbhallens (återförsäljare) personal som ställde upp, ris till Handan för dålig kvalitetskontroll. Ros till min familj och mig själv för tålamodet.

I ärlighetens namn bör jag tillägga följande. Jag använder USB Downloader mycket sällan idag men när jag gör det då fungerar det. Vid överföring sätter jag boxen i menyläge eftersom jag vill förhindra att boxen gör något annat samtidigt. Kanske har det en betydelse, kanske inte. Jag fördjupar mig inte i det problemet längre eftersom jag använder en annan och mycket snabbare metod idag.

Vad som är (var) fel kan man bara spekulera i. Det kan vara själva maskinvara eller programvara i boxen. Men det kan också vara att filsystemet på disken inte är konsistent av någon anledning. Boxen själv kan använda mer information om filerna än USB Downloader och då blir det rätt i boxen men fel i datorn. Ett möjlig experiment vore att formatera om disken helt. Tyvärr går detta inte att göra i boxen. När boxens programvara upptäcker att disken är redan formaterad då gör den bara en snabbformatering. Man behöver ta ur disken och sätta den i en dator och därefter nollställa hela disken helt inklusive systemareor. I Linux finns det möjlighet att göra detta. Man låter Linux skriva binär nollor över hela disken, från den första byten till den sista. Detta tar tid, flera timmar även för små diskar. När man därefter sätter disken i boxen igen och formaterar då görs det en fullständig omformatering vilket tar tid, men inte så lång. Jag har gjort det en gång med en mindre disk hos en kompis. Det fungerar bra men det är bara för de som förstår hur man använder kommandot ”dd” i Linux och dessutom inte tvekar inför en stjärnmejsel, skruvar, flatkabel, IDE kontaker etc.

En annan felkälla (även på min nuvarande box) är att om inspelningen är gjord mha timeshift och den är längre än 90 min (programmet alltså, inte skiftet) då blir den resulterande filen oanvändbar, även i boxen. Detta gör att man inte kan spela in de flesta filmer från timeshift eftersom dessa är oftast längre än 90 minuter, speciellt med all reklam. Jag har frågat Dilog (och därmed Handan) om man inte kan koppla ländgen på ett timeshiftat program till samma inställning som för den vanliga inspelningslängden. Dilog håller med att det vore bra.

/Mikael

Efter mycket irritation och felsökning har jag äntligen lyckats avgöra vad som händer. Vid överföring via USB till datorn kan boxen blanda ihop flera inspelningar, även borttagna sådana. Det yttrar sig genom att filstorleken är den som du förväntat dig, men vid analys i t.ex ProjectX så ser man att där finns data från andra kanaler och krypterade paket som ännu inte avkodats. Kollar man just på dessa istället för den förstörda dataström man egentligen ville ha, så ser man att det är från kanaler som ligger på andra muxar, och program som inte sändes vid samma tid.

Jag funderar på om detta fenomen kan bero på att något kommit i otakt på disken i samband med att den hängt sig vid en radering. Har inte 100% verifierat att det stämmer, men jag fick en känsla av att tillgängligt diskutrymme krympte efter varje hängning och drog slutsatsen att filerna fortfarande upptog allokerat utrymme på disken och att bara själva filnamnet försvann ur listan. Sedan jag återigen började starta om disken en gång per dygn har jag helt sluppit den typen av hängningar, och jag har inte riktigt lust att provocera fram just det felet för att bekräfta min misstanke.

Jag kan bekräfta att jag har haft detta eller liknande problem. Vid överföring via USB Downloader var filerna inte användbara längre trots att de fungerade i boxen. Körde man tillbaka filen till boxen så fungerade den inte heller i boxen. Originalfilen som fanns kvar i boxen under ett annat namn fortsatte att fungera. Det var samma problem både för program inspelade från de fria kanalerna som från betalkanalerna som före överföring avkodades i boxen. Jag har aldrig provat detta med icke avkodade inspelningar eftersom det inte finns någon poäng med det.

Problemet löstes med byte av box. Det krävdes 2 byten eftersom den ena boxen blev skadad vid transport till mig. Ros till Dilogs (Martin) och Webbhallens (återförsäljare) personal som ställde upp, ris till Handan för dålig kvalitetskontroll. Ros till min familj och mig själv för tålamodet.

I ärlighetens namn bör jag tillägga följande. Jag använder USB Downloader mycket sällan idag men när jag gör det då fungerar det. Vid överföring sätter jag boxen i menyläge eftersom jag vill förhindra att boxen gör något annat samtidigt. Kanske har det en betydelse, kanske inte. Jag fördjupar mig inte i det problemet längre eftersom jag använder en annan och mycket snabbare metod idag.

Vad som är (var) fel kan man bara spekulera i. Det kan vara själva maskinvara eller programvara i boxen. Men det kan också vara att filsystemet på disken inte är konsistent av någon anledning. Boxen själv kan använda mer information om filerna än USB Downloader och då blir det rätt i boxen men fel i datorn. Ett möjlig experiment vore att formatera om disken helt. Tyvärr går detta inte att göra i boxen. När boxens programvara upptäcker att disken är redan formaterad då gör den bara en snabbformatering. Man behöver ta ur disken och sätta den i en dator och därefter nollställa hela disken helt inklusive systemareor. I Linux finns det möjlighet att göra detta. Man låter Linux skriva binär nollor över hela disken, från den första byten till den sista. Detta tar tid, flera timmar även för små diskar. När man därefter sätter disken i boxen igen och formaterar då görs det en fullständig omformatering vilket tar tid, men inte så lång. Jag har gjort det en gång med en mindre disk hos en kompis. Det fungerar bra men det är bara för de som förstår hur man använder kommandot ”dd” i Linux och dessutom inte tvekar inför en stjärnmejsel, skruvar, flatkabel, IDE kontaker etc.

/Mikael

<{POST_SNAPBACK}>

På din beskrivning låter det som om du haft exakt samma problem. Maskinvaran har jag redan tagit ut ur ekvationen eftersom allt fungerar i boxen. Det är bara inspelningar som förts över till datorn och sedan tillbaka som inte funkar, och med hjälp av ProjectX har jag kunnat visa att boxen feladresserar filerna just vid överföring via USB Downloader men inte i själva boxen. Felet måste alltså ligga i antingen USB Downloader eller i den del av firmware som hanterar kommunikationen mellan hårddisken och USB Downloader. Att byta box hjälper alltså inte mot just detta problem.

Det är möjligt att det är filsystemet som behöver initialiseras från grunden. Eftersom jag är väl bekant med hårdvaran och Linux så skulle jag kunna göra det du föreslår, men eftersom jag inte vill bli av med garantin så gör jag det inte. Dessutom vill jag först föra över de filer jag vill spara, och det går ju inte med USB Downloader i dagsläget. Eftersom jag har kunnat isolera felet till att orsakas av mjukvara, ser jag inte heller någon anledning att meka med hårdvaran.

Självklart har även jag enbart fört över avkodade inspelningar, men uppe i dessa har det blandats in andra inspelningar som ännu inte varit avkodade i boxen.

Ironiskt nog kan det alltså vara så att det enda säkra sättet att få ut inspelningar ur boxen är att modda den med USB2... vilket jag inte tänker göra dels på grund av garantin, dels på grund av att boxen faktiskt ska fungera som utannonserat utan att användaren behöver gå in själv och modifiera hårdvaran... även om det innebär att jag får sitta kvar med USB 1.1 så ska den åtminstone upp i ca 12Mbit/s (som boxen KAN hålla igång hårdvarumässigt men inte gör av oklara orsaker som säkert beror på dåligt skriven referensmjukvara från Handan) och föra över filerna korrekt för att boxen ska kunna anses uppfylla Dilogs specifikationer.

Vad som kanske skulle hjälpa i att isolera hur felet uppstår (och även porta verktyget till Mac/Linux!) vore att analysera rådatan som sänds över USB, vilka kommandon som skickas till/från boxen och så vidare... men det har jag inte hittat några (gratis) verktyg för, och eftersom jag inte är programmeringskunnig (och i synnerhet inte på PowerPC) så kan jag nog inte få ut så mycket matnyttig information ur en sådan dump ändå...

Jag funderar på om detta fenomen kan bero på att något kommit i otakt på disken i samband med att den hängt sig vid en radering. Har inte 100% verifierat att det stämmer, men jag fick en känsla av att tillgängligt diskutrymme krympte efter varje hängning och drog slutsatsen att filerna fortfarande upptog allokerat utrymme på disken och att bara själva filnamnet försvann ur listan. Sedan jag återigen började starta om disken en gång per dygn har jag helt sluppit den typen av hängningar, och jag har inte riktigt lust att provocera fram just det felet för att bekräfta min misstanke.

<{POST_SNAPBACK}>

Det är mycket möjligt att du är på rätt spår - kan nämligen inte påminna mig att jag sett detta felet förrän efter att en radering hängde sig. Hade inte heller några svarta inspelningar innan dess, och det har vi ju vid det här laget också fastställt med ganska god säkerhet att det beror på mjukvaran, eftersom det faktiskt ofta går att få igång svarta inspelningar (helt eller delvis) med lite tricksande. Kanske är de två felen relaterade på så vis att det är feladresseringar av hårddisken som orsakar båda felen? Detta tål att titta lite närmare på!

Redigerat av DVBgeek, 01 december 2006 - 15:03.

Jag har plockat ut några filmer via usb ur min 550 för att kunna titta i min bärbara dator när jag är ute och reser. Den .hav fil jag får ut vad är det för något? Ska man konvrtera denna fil eller finns det något program som kan spela upp .hav filer?

Jag funderar på om detta fenomen kan bero på att något kommit i otakt på disken i samband med att den hängt sig vid en radering. Har inte 100% verifierat att det stämmer, men jag fick en känsla av att tillgängligt diskutrymme krympte efter varje hängning och drog slutsatsen att filerna fortfarande upptog allokerat utrymme på disken och att bara själva filnamnet försvann ur listan. Sedan jag återigen började starta om disken en gång per dygn har jag helt sluppit den typen av hängningar, och jag har inte riktigt lust att provocera fram just det felet för att bekräfta min misstanke.

<{POST_SNAPBACK}>

Det är mycket möjligt att du är på rätt spår - kan nämligen inte påminna mig att jag sett detta felet förrän efter att en radering hängde sig. Hade inte heller några svarta inspelningar innan dess, och det har vi ju vid det här laget också fastställt med ganska god säkerhet att det beror på mjukvaran, eftersom det faktiskt ofta går att få igång svarta inspelningar (helt eller delvis) med lite tricksande. Kanske är de två felen relaterade på så vis att det är feladresseringar av hårddisken som orsakar båda felen? Detta tål att titta lite närmare på!

<{POST_SNAPBACK}>

Svarta inspelningar hade jag några stycken långt innan jag första gången råkade ut för hängning vid radering, så jag tror inte det finns något samband.

Jag är inte helt övertygad om att svarta inspelningar beror på mjukvarufel. Två, tre av de svarta inspelningar jag haft sammanföll med att tuner 2 hängt sig ("No signal" nästa gång man försökt starta en inspelning) och krävt omstart av boxen. Lite svårt att entydigt peka på hårdvara eller mjukvara, det kan ju exempelvis vara så att mjukvaran skickar en otillåten instruktion till signalbehandlingen så att den hänger sig.

Ironiskt nog kan det alltså vara så att det enda säkra sättet att få ut inspelningar ur boxen är att modda den med USB2... vilket jag inte tänker göra dels på grund av garantin, dels på grund av att boxen faktiskt ska fungera som utannonserat utan att användaren behöver gå in själv och modifiera hårdvaran... även om det innebär att jag får sitta kvar med USB 1.1 så ska den åtminstone upp i ca 12Mbit/s (som boxen KAN hålla igång hårdvarumässigt men inte gör av oklara orsaker som säkert beror på dåligt skriven referensmjukvara från Handan) och föra över filerna korrekt för att boxen ska kunna anses uppfylla Dilogs specifikationer.

Vad som kanske skulle hjälpa i att isolera hur felet uppstår (och även porta verktyget till Mac/Linux!) vore att analysera rådatan som sänds över USB, vilka kommandon som skickas till/från boxen och så vidare... men det har jag inte hittat några (gratis) verktyg för, och eftersom jag inte är programmeringskunnig (och i synnerhet inte på PowerPC) så kan jag nog inte få ut så mycket matnyttig information ur en sådan dump ändå...

Boxen uppfyller väl egentligen specen från Dilog vad gäller USB, så även om vi kan hoppas på bättre hastighet så tvivlar jag på att klagomål på just denna punkt får särskilt hög prioritet. Några 12Mbit/s kan vi aldrig få, det är praktiskt omöjligt, men det borde definitivt gå att komma högre än idag. Sen vet vi ju heller inte hur slug mjukvaran från Finepass är, för USB är det ju så att USB-hosten gör grovjobbet. Om protokollet är klumpigt och USB-hosten illa kodad så kan det straffa hastigheten ganska ordentligt.

Jag har inga tips om verktyg för att sniffa på USB-data, hade den använt några av de generella interfacen (USB-kablar till mobiltelefoner installeras ofta som en COM-port) så hade det nog varit lättare. Däremot låter det inte troligt att det som skickas fram och åter över tråden skulle vara styrt av vilken processor som sitter i boxen så det går säkert att tolka en sån dump även utan PowerPC-kunskap. Att peka ut vilken part som klantar sig i detta fall bedömer jag dock vara svårare.

Boxen uppfyller väl egentligen specen från Dilog vad gäller USB, så även om vi kan hoppas på bättre hastighet så tvivlar jag på att klagomål på just denna punkt får särskilt hög prioritet. Några 12Mbit/s kan vi aldrig få, det är praktiskt omöjligt, men det borde definitivt gå att komma högre än idag. Sen vet vi ju heller inte hur slug mjukvaran från Finepass är, för USB är det ju så att USB-hosten gör grovjobbet. Om protokollet är klumpigt och USB-hosten illa kodad så kan det straffa hastigheten ganska ordentligt.

Jag har inga tips om verktyg för att sniffa på USB-data, hade den använt några av de generella interfacen (USB-kablar till mobiltelefoner installeras ofta som en COM-port) så hade det nog varit lättare. Däremot låter det inte troligt att det som skickas fram och åter över tråden skulle vara styrt av vilken processor som sitter i boxen så det går säkert att tolka en sån dump även utan PowerPC-kunskap. Att peka ut vilken part som klantar sig i detta fall bedömer jag dock vara svårare.

<{POST_SNAPBACK}>

Vad gäller Dilogs spec så säger de att man ska kunna ta backup av sina inspelningar via denna anslutning. Eftersom det inte fungerar med någon större stabilitet i dagsläget (har flera timmars material på boxen som jag inte kan få ut någon användbar backup på) så uppfyller den ju inte just den delen av specifikationen. Vad gäller hastigheten så är boxen godkänd för en throughput på 80Mbit/s totalt (inte på USB-porten förstås, men systemet som sådant), och jag har sett många USB2-enheter som lätt håller uppe en stabil hastighet på nästan 480Mbit/s, så det finns ingen teknisk anledning till varför inte denna box skulle kunna upprätthålla nästan 12Mbit/s stabilt - om min gamla PowerPC G3 klarar det så borde väl rimligen denna boxen också klara det, den har ju inget komplext operativ som ligger under och tar resurser. Chipet som hanterar kommunikationen, är samma chip som sitter i Creative Nomad Jukebox, och ska enligt Philips klara 14Mbit/s. Om man inte kan förbättra hastigheten så borde man åtminstone kunna optimera hanteringen så att överföringar inte stör inspelnings- och timeshiftfunktionerna.

Hittade faktiskt detta verktyg för att kolla på rådatan som går via USB: http://sourceforge.n...jects/usbsnoop/
Men som sagt, eftersom jag inte har någon erfarenhet av programmering lär jag inte få ut något användbart med detta iallafall. Kanske någon mer kunnig vill ta över?

Redigerat av DVBgeek, 02 december 2006 - 18:35.

På din beskrivning låter det som om du haft exakt samma problem. Maskinvaran har jag redan tagit ut ur ekvationen eftersom allt fungerar i boxen. Det är bara inspelningar som förts över till datorn och sedan tillbaka som inte funkar, och med hjälp av ProjectX har jag kunnat visa att boxen feladresserar filerna just vid överföring via USB Downloader men inte i själva boxen. Felet måste alltså ligga i antingen USB Downloader eller i den del av firmware som hanterar kommunikationen mellan hårddisken och USB Downloader. Att byta box hjälper alltså inte mot just detta problem.

Jag vet inte om jag skulle tagit maskinvaran ut ur ekvationen än. Fel i filsystemet på boxens disk kan bero på tillfälliga (intermittenta) fel i maskinvaran. Blir det t.ex. fel i FAT tabellen så blir det fel vid överföring till/från datorn med USB Downloader. Att boxen kan spela filer rätt ändå kan bero på att boxens programvara kan utnyttja mer än bara FAT. Vi vet att det finns någon sort sekundär struktur i själva filerna. Om boxen utnyttjar den och USB Downloader inte (det skall ju räcka med FAT i normala fall) då får vi just den här effekten. Det kan också vara tvärtom.

Det är möjligt att det är filsystemet som behöver initialiseras från grunden. Eftersom jag är väl bekant med hårdvaran och Linux så skulle jag kunna göra det du föreslår, men eftersom jag inte vill bli av med garantin så gör jag det inte. Dessutom vill jag först föra över de filer jag vill spara, och det går ju inte med USB Downloader i dagsläget. Eftersom jag har kunnat isolera felet till att orsakas av mjukvara, ser jag inte heller någon anledning att meka med hårdvaran.

Om du vill spara filer och USB Downloader inte fungerar då är GetHAV det enda hoppet du har. Det är just för ett sådant ändamål som GetHAV har tagits fram till att börja med. Det var fel på en av Finepass programvaruuppdateringar som lämnade ett kaos på disken efter sig. Folk ville rädda vad som räddas kunde och då började man jobba med reverse engineering av filsystemet och på GetHAV.

Det finns delade (juridiska) åsikter om huruvida själva faktum att man tar ut disken och sätter den tillbaka påverkar garantiåtagandet. Dessutom är bevisläget väldigt svårt. Detta utmynnar i frågan om hur flexibla vill alla inblandade vara. Vill man vara flexibel och har de rätta kunskaper så skulle man kunna göra på följande sätt.

Ta ut disken. Sätt den i en Linux maskin. Kör dd och kopiera hela disken till en annan helst likadan disk. Nu har du 2 exakt lika diskar. Sätt tillbaka den första disken i boxen. Få boxen utbytt. Den andra disken kan du leka med. Anslut disken till en XP maskin. Kör GetHAV. Hämta filerna. Det kanske fungerar. Innan du sätter tillbaka den första disken i boxen kan du ju alltid prova med en tredje tom disk som du formaterar i boxen. Fungerar den med USB Downloader? Ett annat alternativ är att sätta boxens disk direkt i XP (låt INTE XP initialisera den – då är det ajöss) och köra GetHAV. Helst, låt ett proffs göra allt detta.

Ironiskt nog kan det alltså vara så att det enda säkra sättet att få ut inspelningar ur boxen är att modda den med USB2... vilket jag inte tänker göra dels på grund av garantin, dels på grund av att boxen faktiskt ska fungera som utannonserat utan att användaren behöver gå in själv och modifiera hårdvaran... även om det innebär att jag får sitta kvar med USB 1.1 så ska den åtminstone upp i ca 12Mbit/s (som boxen KAN hålla igång hårdvarumässigt men inte gör av oklara orsaker som säkert beror på dåligt skriven referensmjukvara från Handan) och föra över filerna korrekt för att boxen ska kunna anses uppfylla Dilogs specifikationer.

Jag håller med. Boxen bör fungera som utlovat men fel kan inträffa och då är det bara att byta. Trots allt är Dilog en av de bästa boxarna på marknaden. Hade de bara koll på kvalitetssäkring, bättre USB Downloader, och dokumentation över filsystemet och USB protokollet samt några andra detaljer som är mycket enkla att åtgärda i programvaran så hade de sopat mattan med resten. Plus att de hade fått massor med tilläggsapplikationer från andra aktörer inklusive öppen source. ”Use the source Jedi!”

Moddningen är inte bra. Garanti är en anledning. Men det finns alvarligare invändningar. Jag riskerar här att bli korsfäst av modd-gänget men det kan inte hjälpas. Tekniskt är moddingen som princip helt ok. Men den implementation som beskrivs i detta forum är under all kritik. Som jag ser det kan den leda till just sådana diskstrukturfel som vi diskuterar och i olyckliga fall även till maskinvarufel. Så som beskrivet kopplas ju disken så att den styrs både från boxen och från datorn samtidigt. Eftersom disken strömförsörjs från boxen måste boxen vara på när man kör från datorn via den extra USB/IDE adaptern. Den IDE T-kabel som används har inte heller något skydd mellan de 2 grenarna (en till boxen och en till USB/IDE adaptern). Därför är risken överhängande att både boxen och datorn får för sig att styra disken samtidigt och resultatet då blir kalabalik. Vidare är vare sig boxens eller USB/IDE adapterns elektronik gjorda för att få signal från det hållet (från USB/IDE till boxen, och från boxen till USB/IDE). Så bygger man inte elektronik.

Därmed är det inte sagt att själva principen är fel. Men då krävs det elektronik av helt annan komplexitetsgrad. När disken används av USB/IDE adaptern då måste den kopplas helt från boxens elektronik och tvärtom. Alla trådar. Ett bra projekt för ett 3-betygsarbete på KTH, Chalmers, mm.

Vad som kanske skulle hjälpa i att isolera hur felet uppstår (och även porta verktyget till Mac/Linux!) vore att analysera rådatan som sänds över USB, vilka kommandon som skickas till/från boxen och så vidare... men det har jag inte hittat några (gratis) verktyg för, och eftersom jag inte är programmeringskunnig (och i synnerhet inte på PowerPC) så kan jag nog inte få ut så mycket matnyttig information ur en sådan dump ändå...

Det bör finnas en USB-sniffer programvara under XP som skulle gå att köra samtidigt som USB Downloader. Problemet är snarare att en sådan reverse engineering kräver mycket och svårt jobb och tid – och då behövs det motivation. Det vore mycket enklare om Dilog dokumenterade protokollet. Som andra ovan tror jag inte heller att kunskap om PowerPC är nödvändig. Snarare en Sherlock Holmes läggning och stor erfarenhet av olika protokoll och oändligt tålamod.

Det är mycket möjligt att du är på rätt spår - kan nämligen inte påminna mig att jag sett detta felet förrän efter att en radering hängde sig. Hade inte heller några svarta inspelningar innan dess, och det har vi ju vid det här laget också fastställt med ganska god säkerhet att det beror på mjukvaran, eftersom det faktiskt ofta går att få igång svarta inspelningar (helt eller delvis) med lite tricksande. Kanske är de två felen relaterade på så vis att det är feladresseringar av hårddisken som orsakar båda felen? Detta tål att titta lite närmare på!

Jag tror också att svarta inspelningar är ett helt annat fenomen.
/Mikael

Jag vet inte om jag skulle tagit maskinvaran ut ur ekvationen än. Fel i filsystemet på boxens disk kan bero på tillfälliga (intermittenta) fel i maskinvaran. Blir det t.ex. fel i FAT tabellen så blir det fel vid överföring till/från datorn med USB Downloader. Att boxen kan spela filer rätt ändå kan bero på att boxens programvara kan utnyttja mer än bara FAT. Vi vet att det finns någon sort sekundär struktur i själva filerna. Om boxen utnyttjar den och USB Downloader inte (det skall ju räcka med FAT i normala fall) då får vi just den här effekten. Det kan också vara tvärtom.

Den sekundära strukturen i filerna borde väl rimligtvis inte innehålla adresseringsinformation. Boxens operativsystem måste ju först läsa den "vanliga" filtabellen för att hitta filen, och om den är fel så vore det ju fullständigt meningslöst att lägga in adresseringsinformation i själva filen. Det finns ju folk på detta forum som identiferat vad som utgör "Handan-specifik" information i filen och tvättar bort det - vore kanske bra att också kunna göra tvärtom (ta ut just den data som inte har med TS-formatet att göra) för en analys av dess innehåll.

Om du vill spara filer och USB Downloader inte fungerar då är GetHAV det enda hoppet du har. Det är just för ett sådant ändamål som GetHAV har tagits fram till att börja med. Det var fel på en av Finepass programvaruuppdateringar som lämnade ett kaos på disken efter sig. Folk ville rädda vad som räddas kunde och då började man jobba med reverse engineering av filsystemet och på GetHAV.

Det finns delade (juridiska) åsikter om huruvida själva faktum att man tar ut disken och sätter den tillbaka påverkar garantiåtagandet. Dessutom är bevisläget väldigt svårt. Detta utmynnar i frågan om hur flexibla vill alla inblandade vara. Vill man vara flexibel och har de rätta kunskaper så skulle man kunna göra på följande sätt.

Ta ut disken. Sätt den i en Linux maskin. Kör dd och kopiera hela disken till en annan helst likadan disk. Nu har du 2 exakt lika diskar. Sätt tillbaka den första disken i boxen. Få boxen utbytt. Den andra disken kan du leka med. Anslut disken till en XP maskin. Kör GetHAV. Hämta filerna. Det kanske fungerar. Innan du sätter tillbaka den första disken i boxen kan du ju alltid prova med en tredje tom disk som du formaterar i boxen. Fungerar den med USB Downloader? Ett annat alternativ är att sätta boxens disk direkt i XP (låt INTE XP initialisera den – då är det ajöss) och köra GetHAV. Helst, låt ett proffs göra allt detta.

Själv har jag kunskapen och den tekniska möjligheten, men eftersom boxen är i ständig användning på ett eller annat sätt är det svårt för mig att hitta tiden till att ta boxen ur bruk och göra dessa saker. Dessutom vill jag absolut ha ett OK från Dilog innan jag öppnar boxen.

Dilog säger själva att det inte finns några "user exchangeable parts" i boxen från deras sätt att se det - traditionellt är ju hårddisken en sådan men inte enligt Dilog alltså.

Dessutom verkar det som om GetHAV inte längre är tillgängligt - Finepass har lagt ner supporten och även forumet är nedlagt (

Jag håller med. Boxen bör fungera som utlovat men fel kan inträffa och då är det bara att byta. Trots allt är Dilog en av de bästa boxarna på marknaden. Hade de bara koll på kvalitetssäkring, bättre USB Downloader, och dokumentation över filsystemet och USB protokollet samt några andra detaljer som är mycket enkla att åtgärda i programvaran så hade de sopat mattan med resten. Plus att de hade fått massor med tilläggsapplikationer från andra aktörer inklusive öppen source. ”Use the source Jedi!”

Hela resonemanget ovan återspeglar exakt min tanke. Själva anledningen till att jag köpte just denna box var att den var den mest avancerade Boxer-godkända boxen på marknaden (även om jag redan från början visste om att det fanns problem med den) och för att med sin PowerPC-baserade arkitektur borde den kunna utvecklas långt bortom de möjligheter den hade från start genom open-source.

Jag tror att många av de problem vi hittat hittils hade kunnat fixas bra mycket snabbare om Dilog varit lite lyhörda för sina användare och släppt källkoden till USB Downloader och specifikationer på filsystem och protokoll, samt kanske delar av firmware som man identifierat problem i.

Att byta boxen tycker jag däremot känns något omotiverat när det med 99% sannolikhet är mjukvaran i den som det är fel på. Dessutom skulle det ju innebära att vara utan boxen under ett antal dagar och det är inte ett alternativ för mig eftersom jag använder PVR-funktionerna varje dag.

Andra tillverkare av samma box har haft samma problem och olika tillverkare har fixat olika saker men allt har till sist isolerats till att ha orsakats av firmware. Det finns, så vitt jag har sett, ingen anledning att tro att några problem med boxen orsakas av dålig hårdvara, med ett eventuellt undantag för problemen med att tuner 2 kan låsa sig ibland. Det finns flera problem på Dilog som jag vet att andra tillverkare har fixat i sina mjukvaror. Alla använder dock samma USB Downloader så ingen har fixat, eller förmodligen ens letat, efter några problem i den.

Skulle gärna se att Dilog aktiverade fler funktioner i USB Downloader också, t.ex att kunna ladda ner filtabellen och göra benchmarks på överföringshastigheten. Hade USB Downloader varit open source hade vi dessutom säkert kunnat snygga till gränssnittet och göra det mer logiskt samt porta det till andra populära operativsystem.

Moddningen är inte bra. Garanti är en anledning. Men det finns alvarligare invändningar. Jag riskerar här att bli korsfäst av modd-gänget men det kan inte hjälpas. Tekniskt är moddingen som princip helt ok. Men den implementation som beskrivs i detta forum är under all kritik. Som jag ser det kan den leda till just sådana diskstrukturfel som vi diskuterar och i olyckliga fall även till maskinvarufel. Så som beskrivet kopplas ju disken så att den styrs både från boxen och från datorn samtidigt. Eftersom disken strömförsörjs från boxen måste boxen vara på när man kör från datorn via den extra USB/IDE adaptern. Den IDE T-kabel som används har inte heller något skydd mellan de 2 grenarna (en till boxen och en till USB/IDE adaptern). Därför är risken överhängande att både boxen och datorn får för sig att styra disken samtidigt och resultatet då blir kalabalik. Vidare är vare sig boxens eller USB/IDE adapterns elektronik gjorda för att få signal från det hållet (från USB/IDE till boxen, och från boxen till USB/IDE). Så bygger man inte elektronik.

Jag hade inte tänkt på det men du har helt rätt och det är ju ännu en anledning att Dilog bör fixa problemen med sin egen USB-koppling så att folk inte ser sig tvungna att modda sina boxar.
För en som för över inspelningar ofta blir det ju också snabbt opraktiskt att öppna boxen och plocka ut hårddisken och sätta tillbaka den vareviga gång.

Det bör finnas en USB-sniffer programvara under XP som skulle gå att köra samtidigt som USB Downloader.

<{POST_SNAPBACK}>

Se mitt inlägg ovan - SnoopyPro borde duga för den som har kunskapen som krävs (vilket inte jag har i detta fall). Den lägger sig "runt" boxens drivrutin och loggar all data som kommer via den drivrutinen.

EDIT: Hittade ytterligare tre användare som ser ut att ha precis samma problem på sina Handan-kloner. En av dom är en DT-550 men det intressanta är att de två andra är en finsk Handan DVB-T 6000 och en Legend PVR-160. Båda dessa andra boxar är också kloner av "Handan DF 7000 T Twin" precis som vår egen DT-550.
Vad än problemet beror på, så kan vi alltså tryggt säga att det inte är Dilogs fel (och det trodde jag aldrig heller - dom har verkligen gjort ett bra jobb med att fixa boxens problem så här långt) utan att buggen härstammar från koreanska Handans referens-firmware.

Redigerat av DVBgeek, 03 december 2006 - 14:16.

Den sekundära strukturen i filerna borde väl rimligtvis inte innehålla adresseringsinformation.

Det är precis vad den gör.

Boxens operativsystem måste ju först läsa den "vanliga" filtabellen för att hitta filen, och om den är fel så vore det ju fullständigt meningslöst att lägga in adresseringsinformation i själva filen.

Ja, så går det till om man har ett OS. Saker och ting är mycket enklare i boxens firmware än så. Det finns inget OS där om man med OS menar vad man brukar mena med det i modern tid. Och det är en del av problemet, inte bara för det vi diskuterar just nu utan även för andra saker. Jag skulle tro att många problem i klassen ”2 mottagare samtidigt” beror på att man inte har en riktig multikörning och ett riktigt filsystem i boxens programvara. Jag skall beskriva ett sådant problem, som har hänt några gånger däribland igår i mitt nästa inlägg.

Om FAT är ok då skall det räcka med den informationen för att ta fram hela sekvensen av alla sektorer som utgör en fil. Men om FAT är fel då fungerar det inte. Men om man kan hitta det första klustret då är jag övertygad om att med info i detta kan man hitta nästa, osv.

Jämför med hur fsck för ext2 filsystem fungerar. Man har en viss redundans i filsystemet som kan utnyttjas av programvara som är skrivet för ändamålet.

Det finns ju folk på detta forum som identiferat vad som utgör "Handan-specifik" information i filen och tvättar bort det - vore kanske bra att också kunna göra tvärtom (ta ut just den data som inte har med TS-formatet att göra) för en analys av dess innehåll.

Ja, det är lätt att hoppa över ”hav paketeringen” och få tillbaka TS strömmen, eller att ta reda på ”hav delarna”. Jag har själv skrivit ett enkelt Java program för ändamålet. Det är just i denna paketering som den redundanta informationen ligger. Arbete med analys av innehållet i denna paketering pågår, dock med en väldigt låg aktivitet i brist på motivation. Att hoppa över är lätt, att analysera och utnyttja är svårare, att återskapa den så att boxen kan använda den är ännu svårare. Den tredje informationsbiten är den filkatalog (directory) som också finns på disken och skall analyseras och nyttjas.

Men ingenting av detta hjälper om man inte har fullständig info om det protokoll som USB Downloader använder och boxen lyssnar till, om man vill gå den vägen vill säga.

Själv har jag kunskapen och den tekniska möjligheten, men eftersom boxen är i ständig användning på ett eller annat sätt är det svårt för mig att hitta tiden till att ta boxen ur bruk och göra dessa saker.

Eftersom du säger att du vill behålla det du nu har på disken och USB Downloader inte fungerar då finns det ingen annan väg. Det går inte att trolla! Skaffa en annan disk, sätt den i boxen så att du kan använda boxen som vanligt. Då kan du jobba i lugn och ro med den första.

Dessutom vill jag absolut ha ett OK från Dilog innan jag öppnar boxen.

Dilog säger själva att det inte finns några "user exchangeable parts" i boxen från deras sätt att se det - traditionellt är ju hårddisken en sådan men inte enligt Dilog alltså.

Det blir nog svårt att få. Å andra sidan och rent juridiskt så bestämmer inte Dilog ensamt om detta. Dessutom så behöver du ju göra det för att uppnå vad som utlovades i specen. Jag hoppas att om du gör det försiktigt så finns det en god chans till att alla parter visar sig vara flexibla, speciellt den part vars fel det ursprungligen är.

Dessutom verkar det som om GetHAV inte längre är tillgängligt - Finepass har lagt ner supporten och även forumet är nedlagt (

Jag kan skicka en fungerande GetHAV till dig om du säger vart jag skall skicka den.

Hela resonemanget ovan återspeglar exakt min tanke. Själva anledningen till att jag köpte just denna box var att den var den mest avancerade Boxer-godkända boxen på marknaden (även om jag redan från början visste om att det fanns problem med den) och för att med sin PowerPC-baserade arkitektur borde den kunna utvecklas långt bortom de möjligheter den hade från start genom open-source.

Hoppas på open-source för firmware i boxen är att hoppas på för mycket, tror jag. Skall du gå den vägen så är det Dreambox du skall titta på. Men var beredd på att hacka innan du får allting rätt, speciellt för att få igång Boxer-kortet. Jag tittade på Dreambox men valde Dilog just av den anledningen. Men kan Dreambox eller någon av återförsäljarna fixa så att Boxer-kortet fungerar direkt på den box som levereras så kommer saken i ett annat läge. Det vore också kul att ha en Dreambox vid sidan om Dilog enbart för att hacka lite och lära sig något. Å andra sidan finns det annat kul att hacka på, en HTPC till exempel.

Jag tror att många av de problem vi hittat hittils hade kunnat fixas bra mycket snabbare om Dilog varit lite lyhörda för sina användare och släppt källkoden till USB Downloader och specifikationer på filsystem och protokoll, samt kanske delar av firmware som man identifierat problem i.

Andra tillverkare av samma box har haft samma problem och olika tillverkare har fixat olika saker men allt har till sist isolerats till att ha orsakats av firmware. Det finns, så vitt jag har sett, ingen anledning att tro att några problem med boxen orsakas av dålig hårdvara, med ett eventuellt undantag för problemen med att tuner 2 kan låsa sig ibland. Det finns flera problem på Dilog som jag vet att andra tillverkare har fixat i sina mjukvaror. Alla använder dock samma USB Downloader så ingen har fixat, eller förmodligen ens letat, efter några problem i den.

Jag tror att en del av problemet är att Sverige är ett litet land och därmed en liten marknad. När Apple specar och låter sina MacBook datorer tillverkas i Asien så är den asiatiska tillverkaren en underleverantör som gör som Apple säger. Jag tror inte att det är samma styrkeförhållanden mellan Dilog och Handan.

Att byta boxen tycker jag däremot känns något omotiverat när det med 99% sannolikhet är mjukvaran i den som det är fel på. Dessutom skulle det ju innebära att vara utan boxen under ett antal dagar och det är inte ett alternativ för mig eftersom jag använder PVR-funktionerna varje dag.

Problemet löstes med ett byte för mig. Ja, min familj blev utan box under 2 längre perioder. Vad göra?

Skulle gärna se att Dilog aktiverade fler funktioner i USB Downloader också, t.ex att kunna ladda ner filtabellen och göra benchmarks på överföringshastigheten. Hade USB Downloader varit open source hade vi dessutom säkert kunnat snygga till gränssnittet och göra det mer logiskt samt porta det till andra populära operativsystem.

Ungefär, de kan ju börja med att se till att den USB Downloader som finns fungerar felfritt. Dock tror jag att den rätta vägen, för nästa Dilog modell, vore att använda ett känt filsystem och implementera USB porten i boxen som en vanlig diskport. Boxen skall uppträda som en disk när den kopplas till en dator. Då behövs det ingen USB Downloader alls och det fungerar under alla OS.

Jag hade inte tänkt på det men du har helt rätt och det är ju ännu en anledning att Dilog bör fixa problemen med sin egen USB-koppling så att folk inte ser sig tvungna att modda sina boxar.
För en som för över inspelningar ofta blir det ju också snabbt opraktiskt att öppna boxen och plocka ut hårddisken och sätta tillbaka den vareviga gång.

Jag undrar hur mycket kan Dilog fixa själva utan Handan alltså.

Ja, det blir opraktiskt och det är inte att rekommendera för ”vanliga” användare. Min kompis gör så att han väntar tills disken är full och då kör han över allting till en annan disk och nollställer disken igen. På det sättet blir det inte så ofta.

/Mikael

Jag undrar om det är fler än jag som har observerad följande fenomen vid samtidig timeshift och schemalagd inspelning.

En inspelning är schemalagd på vanligt sätt. Innan den börjar startar man timeshift. Därefter startas den schemalagda inspelningen automatiskt. Innan den är klar stänger man av timeshift. Den schemalagda inspelningen pågår enligt schemat till sin slut. Den fil som lagras har längd 0 och försöker man spela den så avslutas uppspelningen omedelbart.

/Mikael

Boxens operativsystem måste ju först läsa den "vanliga" filtabellen för att hitta filen, och om den är fel så vore det ju fullständigt meningslöst att lägga in adresseringsinformation i själva filen.

Ja, så går det till om man har ett OS. Saker och ting är mycket enklare i boxens firmware än så. Det finns inget OS där om man med OS menar vad man brukar mena med det i modern tid. Och det är en del av problemet, inte bara för det vi diskuterar just nu utan även för andra saker. Jag skulle tro att många problem i klassen ”2 mottagare samtidigt” beror på att man inte har en riktig multikörning och ett riktigt filsystem i boxens programvara. Jag skall beskriva ett sådant problem, som har hänt några gånger däribland igår i mitt nästa inlägg.

Om FAT är ok då skall det räcka med den informationen för att ta fram hela sekvensen av alla sektorer som utgör en fil. Men om FAT är fel då fungerar det inte. Men om man kan hitta det första klustret då är jag övertygad om att med info i detta kan man hitta nästa, osv.

Jämför med hur fsck för ext2 filsystem fungerar. Man har en viss redundans i filsystemet som kan utnyttjas av programvara som är skrivet för ändamålet.

Jag fattar fortfarande inte hur en sådan "sekundär" struktur inne i själva filerna kan göra att fel i filsystemet inte påverkar vanlig uppspelning. I vissa fall har jag sett filer som haft upp till 50% av innehållet ersatt med andra inspelningar vid överföring, och ändå fungerar orginalet 100% i boxen. Någonstans måste det ju då finnas en plats där den "sekundära" strukturen tillhör en annan inspelning och boxens vanliga uppspelning går bet. Men icke! Mysteriet kvarstår...

Men ingenting av detta hjälper om man inte har fullständig info om det protokoll som USB Downloader använder och boxen lyssnar till, om man vill gå den vägen vill säga.

Hoppas SnoopyPro kan hjälpa om du har den kunskap som krävs... jag har det iallafall inte - ibland önskar man ju att man var fullfjädrad programmerare och inte bara allmänt datanörd.

Eftersom du säger att du vill behålla det du nu har på disken och USB Downloader inte fungerar då finns det ingen annan väg. Det går inte att trolla! Skaffa en annan disk, sätt den i boxen så att du kan använda boxen som vanligt. Då kan du jobba i lugn och ro med den första.

Men å andra sidan borde Dilog fixa USB Downloadern så att jag kan få ut filerna på "rätt" sätt utan att behöva ta ut hårddisken...

Jag kan skicka en fungerande GetHAV till dig om du säger vart jag skall skicka den.

Hittade faktiskt senaste (sista?) versionen här: http://www.haenlein-...ad/GetHAV12.zip

Hoppas på open-source för firmware i boxen är att hoppas på för mycket, tror jag. Skall du gå den vägen så är det Dreambox du skall titta på. Men var beredd på att hacka innan du får allting rätt, speciellt för att få igång Boxer-kortet. Jag tittade på Dreambox men valde Dilog just av den anledningen. Men kan Dreambox eller någon av återförsäljarna fixa så att Boxer-kortet fungerar direkt på den box som levereras så kommer saken i ett annat läge. Det vore också kul att ha en Dreambox vid sidan om Dilog enbart för att hacka lite och lära sig något. Å andra sidan finns det annat kul att hacka på, en HTPC till exempel.

Jag valde Dilog av ungefär samma orsak - eftersom min familj också använder boxen ville jag ha en "dedikerad" box som vem som helst kunde hantera, och därmed också en box som Boxer supportar. Men jag ville också ha något som inte låg så långt ifrån en Dreambox vad gäller möjligheter och kraft. Eftersom jag själv är någorlunda kunnig i Linux hade en Dreambox varit rolig att "meka" med, men då bygger jag hellre en HTPC med CI-kort - men det är varken billigt eller särskilt användarvänligt (för vanliga användare) och skulle kräva allt för mycket ständigt underhåll från min sida. Så det blev en Dilog och även med den många timmars frustrerande felsökning, men jag visste åtminstone vid köpet att det inte skulle bli helt problemfritt (tack vare detta forum). Martin och alla dom andra på Dilog ska iallafall ha ett stort erkännande för att dom fixat timerproblemen, men mycket återstår innan boxen är så bra som den borde ha varit från början...

Hade inte precis något hopp om att Dilog skulle släppa firmware som open source, men kanske vissa delar av den som dom har problem med och vill ha hjälp att fixa (som filsystemet t.ex ).
Däremot en portningsbar open-source version av USB Downloader skulle verkligen behövas och eftersom den ändå inte har något med Boxers kryptering att göra borde det inte finnas något hinder för Dilog eller Handan att släppa den.
Dessutom bygger ju Dilog precis som Dreambox på PowerPC så någon kommer kanske att lyckas köra Linux eller BSD på den framöver, vem vet?

Problemet löstes med ett byte för mig. Ja, min familj blev utan box under 2 längre perioder. Vad göra?

Om det är som du tror och orsaken är en misslyckad radering av en inspelning, så borde ju en om-initialisering av hårddisken lösa problemet utan att kräva byte av boxen. Det är ju inte hårdvaran det är fel på i just detta fall åtminstone.

Ungefär, de kan ju börja med att se till att den USB Downloader som finns fungerar felfritt. Dock tror jag att den rätta vägen, för nästa Dilog modell, vore att använda ett känt filsystem och implementera USB porten i boxen som en vanlig diskport. Boxen skall uppträda som en disk när den kopplas till en dator. Då behövs det ingen USB Downloader alls och det fungerar under alla OS.

Tja, det borde ju kunna implementeras med nuvarande box också med hjälp av en firmware-uppdatering. USB-kontrollern i boxen är nämligen kompatibel med Mass Storage Device Class. Specifikation finns här och Philips egen drivrutin ska finnas någonstans på https://download.semiconductors.com/

Drivrutinen som Dilog tillhandahåller är mycket gammal (och inte WHQL-godkänd) vid det här laget och förmodligen inte ens i närheten av Vista-kompatibel (men jag har inte testat). Creative har en nyare och WHQL-godkänd drivrutin för detta chip men USB Downloader vill inte samarbeta med den drivrutinen. Windows tycker, oavsett vilken drivrutin jag använder, att det är en Nomad Jukebox som jag kopplar till datorn...

Jag undrar hur mycket kan Dilog fixa själva utan Handan alltså.

Ja, det blir opraktiskt och det är inte att rekommendera för ”vanliga” användare. Min kompis gör så att han väntar tills disken är full och då kör han över allting till en annan disk och nollställer disken igen. På det sättet blir det inte så ofta.

<{POST_SNAPBACK}>

Det var ju en idé förstås...

Jag undrar om det är fler än jag som har observerad följande fenomen vid samtidig timeshift och schemalagd inspelning.

En inspelning är schemalagd på vanligt sätt. Innan den börjar startar man timeshift. Därefter startas den schemalagda inspelningen automatiskt. Innan den är klar stänger man av timeshift. Den schemalagda inspelningen pågår enligt schemat till sin slut. Den fil som lagras har längd 0 och försöker man spela den så avslutas uppspelningen omedelbart.

/Mikael

<{POST_SNAPBACK}>

Det är möjligt att jag sett något liknande, ibland under sådana omständigheter som du beskriver så finns det två filer sist i PVR-listan med samma namn (namnet som timeshiften fick) och den sista har nollängd. Ingen är markerad som att den håller på att spela in (röd). När den sista inspelningen avslutas får den sista filen sitt riktiga namn och längd.


EDIT: Kanske det borde skapas någon form av enkel bugtracker där vi kan rapportera buggar och ta bort dom allt eftersom Dilog fixar till dom? Ljudbuggen som TEAC fixat t.ex, den tror jag ingen här har rapporterat förut men den existerar även på Dilogen. Den går ut på att ljudet plötsligt försvinner i några sekunder, och uppträder ofta efter att boxen varit igång i ett par timmar. Först trodde jag den hade med hårdvara att göra (överhettning någonstans?) men sedan fick jag nys om att TEAC som också tillverkar en klon av samma box hade fixat den buggen - men många av dom andra buggarna som Dilog fixat kvarstår hos TEAC. Även Grundig, Legend och finska Handan gör ju sina egna firmware till denna box, vore trevligt om dom kunde samarbeta för att stabilisera sina boxar så snabbt som möjligt!

Redigerat av DVBgeek, 03 december 2006 - 20:44.

Jag fattar fortfarande inte hur en sådan "sekundär" struktur inne i själva filerna kan göra att fel i filsystemet inte påverkar vanlig uppspelning. I vissa fall har jag sett filer som haft upp till 50% av innehållet ersatt med andra inspelningar vid överföring, och ändå fungerar orginalet 100% i boxen. Någonstans måste det ju då finnas en plats där den "sekundära" strukturen tillhör en annan inspelning och boxens vanliga uppspelning går bet. Men icke! Mysteriet kvarstår...

Har man sagt A då måste man säga B så här kommer en föreläsning.

En fil består av ett antal delar som kallas kluster eller sektorer beroende på typen av filsystem. Dessa kluster kan ligga i en sammanhängande area på disken vilket de oftast gör på en ny disk men oftast ligger dessa kluster utspridda huller om buller på disken. I ett FAT-baserat filsystem finns det en speciell sammanhängande area som kallas FAT. För varje fil på disken finns en post i FAT som talar om vilka kluster som utgör just den filen och var, var och en av dessa kluster, går att hitta och i vilken sekvens som dessa kluster skall sättas ihop för att få hela filen. Blir det fel i FAT då kan programvaran ”luras” att tro att den sekvens av klustrar den läser tillhör en och samma fil fast det är delar från olika filer och/eller i fel sekvens. Varje kluster kan innehålla själva data och/eller kontrollinfo. Kontrollinfo kan innehålla information om var nästa kluster som hör till samma fil kan hittas på disken – det är den redundanta delen och kallas för pekare. Ett annat program kan alltså läsa filen på ett korrekt sätt om det följer pekare istället för vad FAT säger. Det kan också vara tvärtom, fel i pekarna och rätt i FAT.

Det finns ingen mystik – det finns bara fysik och matematik.

Hoppas SnoopyPro kan hjälpa om du har den kunskap som krävs... jag har det iallafall inte - ibland önskar man ju att man var fullfjädrad programmerare och inte bara allmänt datanörd.

Det är aldrig för sent att fördjupa sig i ett ämne och det är inga helgon som programmerar heller.

Kunskap kanske jag har men det behövs motivation också. Jag har en fungerande ”backup” logistik så varför skulle jag ägna tid (det är mycket tid vi pratar om) på en box vars tillverkare (Dilog/Handan) inte visar ens en enda liten ansats till intresse och/eller hjälp. Nej, skall jag satsa den tiden så blir det på Dreambox eller ännu hellre på en HTPC med ett DVB kort eller två...

Men å andra sidan borde Dilog fixa USB Downloadern så att jag kan få ut filerna på "rätt" sätt utan att behöva ta ut hårddisken...

Jag skulle inte hoppas på det. När det blev fel på Finepass disken efter en firmware uppdatering så struntade de i det. Folk fick göra bäst de ville och då tog folket fram GetHAV.

Jag valde Dilog av ungefär samma orsak - eftersom min familj också använder boxen ville jag ha en "dedikerad" box som vem som helst kunde hantera, och därmed också en box som Boxer supportar. Eftersom jag själv är någorlunda kunnig i Linux hade en Dreambox kanske varit rolig ett tag, men då bygger jag hellre en HTPC med CI-kort - men det är varken billigt eller särskilt användarvänligt (för vanliga användare) och skulle kräva allt för mycket ständigt underhåll från min sida. Så det blev en Dilog och även med den många timmars frustrerande felsökning, men jag visste åtminstone vid köpet att det inte skulle bli helt problemfritt (tack vare detta forum).

Precis, problemet med familjer kan vara att de inte omedelbart inser nyttan med vissa funktioner som en annan slås för eller med. Inte heller det roliga i att få igång någonting som inte tycks fungera. Men har man fått det att funka smidigt då lär de sig uppskatta detta högt, t. o .m på ”det här var det bästa med den här apparaten” nivå.

Så därför är mitt vardagsrum ganska traditionell än så länge medan jag funderar och experimenterar med HTPC och med hur jag vill ha den när den väl tar plats i vardagsrummet. Det är inte helt givet att den nuvarande HTPC paradigmen är helt rätt, framförallt vad gäller styrning och med att man ofta vill göra flera saker samtidigt när man nu har en dator och nätverk med alla deras möjligheter. Sedan har vi pris, storlek, vikt, utseende och fläktljud för de burkar som är flexibla och kraftfulla nog...

Hade inte precis något hopp om att Dilog skulle släppa firmware som open source, men kanske vissa delar av den som dom har problem med och vill ha hjälp att fixa (som filsystemet t.ex ).
Däremot en portningsbar open-source version av USB Downloader skulle verkligen behövas och eftersom den ändå inte har något med Boxers kryptering att göra borde det inte finnas något hinder för Dilog eller Handan att släppa den.

Jag håller med, åtminstone dokumentation över filsystemet, hav-formatet, och USB Downloader protokollet borde de släppa. Däremot har Dilog, som alla andra boxar som använder CAM modul, inget med kryptering att göra alls. Man pumpar bara en krypterad TS ström in i CAM-modulen och ut får man den dekrypterade strömmen. Praktiskt och bra om det inte vore för att CAM-modulen som är en PCMCIA inte går att använda i en dators PCMCIA fack

Tja, det borde ju kunna implementeras med nuvarande box också. USB-kontrollern i boxen är nämligen kompatibel med mass storage class. Specifikation finns här.
Drivrutinen som Dilog tillhandahåller är mycket gammal vid det här laget och förmodligen inte Vista-kompatibel (men jag har inte testat). Creative har en nyare och WHQL-godkänd drivrutin för detta chip men USB Downloader vill inte samarbeta med den drivrutinen. Windows tycker, oavsett vilken drivrutin jag använder, att det är en Nomad Jukebox som jag kopplar till datorn...

Jo, det är tydligen så som den identifierar sig för XP. Mass storage class är en sak, filsystem är en annan – det är den biten som Dilog inte gör via USB.

Det är möjligt att jag sett något liknande, ibland under sådana omständigheter som du beskriver så finns det två filer sist i PVR-listan med samma namn (namnet som timeshiften fick) och den sista har nollängd. Ingen är markerad som att den håller på att spela in (röd). När den sista inspelningen avslutas får den sista filen sitt riktiga namn och längd.

Jo, det har jag också sett. Men igår fick jag bara en fil med nollängd och den förblev noll även efter inspelningen. Jag sparade inte timeshiften heller.

Jag jobbade förut med kommersiell programvarutveckling och när vi hade programvara som hade så många buggar som Dilog/Handan har nu då kallades detta för betaversion – det var före den allmänna releasen alltså. Men det är tydligen inflation på den namngivningen nu för tiden.

Kanske det borde skapas någon form av enkel bugtracker där vi kan rapportera buggar och ta bort dom allt eftersom Dilog fixar till dom? Ljudbuggen som TEAC fixat t.ex, den tror jag ingen här har rapporterat förut men den existerar även på Dilogen. Den går ut på att ljudet plötsligt försvinner i några sekunder, och uppträder ofta efter att boxen varit igång i ett par timmar. Först trodde jag den hade med hårdvara att göra (överhettning någonstans?) men sedan fick jag nys om att TEAC som också tillverkar en klon av samma box hade fixat den buggen - men många av dom andra buggarna som Dilog fixat kvarstår hos TEAC.

Den bugtrackern bör finnas på Dilog siten tillgänglig för allmänheten för läsning och under en viss moderation även för skrivning.

Ljudbuggen är ny för mig, har inte observerat detta. Däremot försvinner ljudet ofta vid byte mellan kanalerna. Det verkar att boxen förstör S/PDIF signalen vid byte så till den milda grad att min Bose går vilse. Det kan vara Bose’s fel också. Det är helt otroligt att herrarna inte kan läsa specar och standarder innantill och göra rätt. Som det är nu måste man testa en ny pryl mot alla kombinationer av alla andra prylar man har för att se om den funkar innan man köper. Sedan klagar de på att det blir så många returer och att distansköplagen utnyttjas till max.

/Mikael

Varje kluster kan innehålla själva data och/eller kontrollinfo. Kontrollinfo kan innehålla information om var nästa kluster som hör till samma fil kan hittas på disken – det är den redundanta delen och kallas för pekare. Ett annat program kan alltså läsa filen på ett korrekt sätt om det följer pekare istället för vad FAT säger. Det kan också vara tvärtom, fel i pekarna och rätt i FAT.

Om det är som du säger så får ju även USB Downloader den informationen, så det borde isåfall "bara" vara en fråga om att faktiskt utnyttja den. Vilket alltså inte görs i dagsläget...

Det är aldrig för sent att fördjupa sig i ett ämne

Kanske sant, men jag har försökt så många gånger och misslyckats att jag nog bör inse att programmering inte är helt min grej och definitivt inte på en sådan nivå att jag kan utläsa hur ett program funkar genom RE...

Jag skulle inte hoppas på det. När det blev fel på Finepass disken efter en firmware uppdatering så struntade de i det. Folk fick göra bäst de ville och då tog folket fram GetHAV.

Tja, Martin på Dilog verkar ju vilja hjälpa iallfall, och man får hoppas att han faktiskt är representativ för sitt företag. Dom har ju lyckats med att stabilisera timern och den uppdatering dom jobbat med sedan i juli (som blir 1.19) kommer, så vitt jag förstod på Martins ord, att bli en mycket stor och spännande uppdatering...

Precis, problemet med familjer kan vara att de inte omedelbart inser nyttan med vissa funktioner som en annan slås för eller med. Inte heller det roliga i att få igång någonting som inte tycks fungera. Men har man fått det att funka smidigt då lär de sig uppskatta detta högt, t. o .m på ”det här var det bästa med den här apparaten” nivå.

Jepp, jag själv kämpar ju med funktioner i boxen som ligger på en högre nivå än vad övriga i familjen vill behöva bry sig med, så för dom funkar ju boxen bra. Hade jag däremot valt en Dreambox eller byggt en HTPC så hade familjen fått stå ut med mycket nertid för uppgraderingar, installation av nya programvaruversioner, betatestning och ostabilitet. Och sådant tålamod tror jag ingen (som inte är tekniker själv) skulle ha bara för att få se på TV...

Jag håller med, åtminstone dokumentation över filsystemet, hav-formatet, och USB Downloader protokollet borde de släppa. Däremot har Dilog, som alla andra boxar som använder CAM modul, inget med kryptering att göra alls.

Intressant, då borde det ju vara nada problem att släppa hela firmware som open source ur Boxers synvinkel iallafall, om den inte har något med krypteringen att göra.
Men oavsett, USB Downloader borde definitivt släppas med källkod för fixning och portning. Har ännu inte fått någon respons på det förslaget från Dilog men jag antar att det isåfall är Handan man måste fråga.

Jo, det är tydligen så som den identifierar sig för XP. Mass storage class är en sak, filsystem är en annan – det är den biten som Dilog inte gör via USB.

Inte riktigt, faktiskt. Hade boxen identifierat sig som en mass storage device, då hade boxen visat sig som en enhet i Diskhantering, GetHAV hade funkat via den inbyggda USB-kopplingen och XP hade klagat på att boxen inte var formatterad med ett Windows-filsystem.

Jag jobbade förut med kommersiell programvarutveckling och när vi hade programvara som hade så många buggar som Dilog/Handan har nu då kallades detta för betaversion – det var före den allmänna releasen alltså. Men det är tydligen inflation på den namngivningen nu för tiden.

Så sant!

Den bugtrackern bör finnas på Dilog siten tillgänglig för allmänheten för läsning och under en viss moderation även för skrivning.

Har redan framfört detta förslag till Martin utan att få något entusiastiskt svar. Han säger att dom läser vårt forum men att dom internt har kommit överens om att dom inte skall svara här utan bara supporta via email och telefon. Ett beslut som man väl får respektera och lita på att dom har bra orsaker.

Ljudbuggen är ny för mig, har inte observerat detta. Däremot försvinner ljudet ofta vid byte mellan kanalerna. Det verkar att boxen förstör S/PDIF signalen vid byte så till den milda grad att min Bose går vilse.

<{POST_SNAPBACK}>

Om du kör signalen via S/PDIF är det nog orsaken att du inte märkt denna bugg - den uppstår förmodligen endast på den interna avkodningen (av MPEG-ljud) och TEAC har bekräftat att det är en bugg i firmware, inte hårdvara, som orsakar det. Däremot har deras firmware andra problem, t.ex har de inte aktiverat möjligheten att ta backup på inspelningar via USB.

Sen vet vi ju heller inte hur slug mjukvaran från Finepass är, för USB är det ju så att USB-hosten gör grovjobbet. Om protokollet är klumpigt och USB-hosten illa kodad så kan det straffa hastigheten ganska ordentligt.

<{POST_SNAPBACK}>

Om du kollar på egenskaperna för USB Downloader så ser du föressten att även denna kommer från Handan. Med tanke på "kvalitén" på deras firmware så skulle jag inte hålla det för osannolikt att en granskning av källkoden till USB Downloader skulle visa ett stort antal buggar och allmänt ineffektiv kod som en bra programmerare enkelt skulle ha fixat och förmodligen aldrig gjort ifrån början. Det är bara en gissning, förstås.

På ämnet firmware har jag iallafall noterat att inga buggar i den tycks härstamma från Dilog. Alla de buggar vi sett hittils har så vitt jag förstått visat sig på alla kloner av Handans boxar och det är alltså enbart Handan som är ansvariga för felen. Att däremot rätta till dom verkar ha fallit på distributörernas axlar, i vårt fall Dilog. Det är ju synd att inte de olika distributörerna har ett närmare samarbete om dessa fixar...

mhakman, jag är föressten lite nyfiken på hur du har löst backupproblematiken - du säger att du har en fungerande logistik för backuppen, men du använder väl inte moddningen (antar jag pga din tekniska förklaring av varför den inte är helt bra), och jag antar att du inte skyfflar hårddisken fram och tillbaka ur boxen hela tiden heller. Hur har du löst det hela?

Redigerat av DVBgeek, 04 december 2006 - 18:40.

Om det är som du säger så får ju även USB Downloader den informationen, så det borde isåfall "bara" vara en fråga om att faktiskt utnyttja den. Vilket alltså inte görs i dagsläget...

Inget program får den – programmen får läsa den själva – vilket alltså USB Downloader inte gör (om det är den Downloader delen som finns på PC eller dess motpart i boxen går inte att säga). Däremot gör programvaran som spelar filer i boxen det bevisligen. Det är helt enkelt två olika programslingor som gör olika saker även när de hämtar data från disken.

Tja, Martin på Dilog verkar ju vilja hjälpa iallfall, och man får hoppas att han faktiskt är representativ för sitt företag. Dom har ju lyckats med att stabilisera timern och den uppdatering dom jobbat med sedan i juli (som blir 1.19) kommer, så vitt jag förstod på Martins ord, att bli en mycket stor och spännande uppdatering...

Martin är en trevlig karl att ha att göra med. Men hans ”rörelsefrihet” är begränsad av att han jobbar på ett företag. Jag har själv varit i sådana lägen där man internt är emot vissa beslut eller lösningar men utåt måste försvara företagets linje. Det är tufft men så länge man inte behöver göra våld på sina moraliska värderingar så går det ju, åtminstone då och då.

Jag kan knappt bärga mig i väntan på den fantastiska 1.19 uppdateringen

Men oavsett, USB Downloader borde definitivt släppas med källkod för fixning och portning. Har ännu inte fått någon respons på det förslaget från Dilog men jag antar att det isåfall är Handan man måste fråga.

Det räcker med protokollet som programvaran i boxen lyssnar till. Resten är en ”piece of cake”. Hellre en formell protokoll definition än en massa kod säger proffsen.

Inte riktigt, faktiskt. Hade boxen identifierat sig som en mass storage device, då hade boxen visat sig som en enhet i Diskhantering, GetHAV hade funkat via den inbyggda USB-kopplingen och XP hade klagat på att boxen inte var formatterad med ett Windows-filsystem.

Det var du, inte jag, som sade att den (eller snarare drivern i XP) är en mass storage class. Jag påpekade bara att mass storage är en sak och filsystem är en annan.

Om du kör signalen via S/PDIF är det nog orsaken att du inte märkt denna bugg - den uppstår förmodligen endast på den interna avkodningen (av MPEG-ljud) och TEAC har bekräftat att det är en bugg i firmware, inte hårdvara, som orsakar det. Däremot har deras firmware andra problem, t.ex har de inte aktiverat möjligheten att ta backup på inspelningar via USB.

Ja, Dilog verkar vara den enda boxen på marknaden vid sidan om Dreambox som har officiellt stöd för detta med USB överföring (eller någon överföring överhuvudtaget). Det är också den främsta anledningen till att jag valde Dilog. Det måste finnas möjligheter att använda DVR (PVR) på samma sätt som man använde VCR. Då lade man banden på hög, nu lägger man diskar eller skivor på hög. Jag kommer aldrig att skaffa en DVR utan den möjligheten. Tillverkarnas ovilja till att implementera detta går inte att begripa. BTW, Dreambox kan lagra filer direkt på en nätverksdisk med ett vanligt filsystem i ett standardiserat och väldokumenterat format så att man slipper att överföra dessa någonstans.

mhakman, jag är föressten lite nyfiken på hur du har löst backupproblematiken - du säger att du har en fungerande logistik för backuppen, men du använder väl inte moddningen (antar jag pga din tekniska förklaring av varför den inte är helt bra), och jag antar att du inte skyfflar hårddisken fram och tillbaka ur boxen hela tiden heller. Hur har du löst det hela?Hur har du löst det hela?

Nej naturligtvis använder jag inte moddningen. Jag har funderat på vad det skulle innebära att implemetera den på det rätta sättet. Det är för mycket jobb för den lilla vinsten man gör. Jag har beskrivit hur min kompis gör. Han har dessutom underlättat det för sig på följande sätt. Han skruvar inte igen kåpan utan låter den ligga bara på – den sitter fint utan skruvar om man inte flyttar boxen, vilket han inte gör. Det innebär att han bara behöver lyfta upp den (SLÅ AV BOXEN FÖRST) när det är så dags. Dessutom är gängorna i plåten svaga och man kan lätt överdra när man skruvar igen. När han för första gången skruvade loss själva disken då fick han först skruva loss den brygga som disken sitter på för att komma åt diskskruvarna som sitter på undersidan. Därefter har han skruvat tillbaka bryggan utan disk. Han har skaffat 4 skruvar med samma dimension som diskskruvarna men utan huvud (det går att såga av huvuden från vanliga skruvar också). Därefter har han skruvat de huvudlösa skruvarna i disken där de ursprungliga skruvarna skulle sitta, till hälften ungefär (säkra med nagellack skulle en modellbyggare säga). På det sättet får disken 4 stycken ”ben” som passar perfekt in i gummibussningar i bryggan (samma gummibussningar som de ursprungliga diskskruvarna gick igenom från undersidan). På det sättet behöver min kompis bara lägga disken på plats på bryggan och så sitter disken där den skall vilandes på bussningarna som sig bör. Kompisen har också bytt ut den ursprungliga IDE kabeln till en längre med ett ”handtag” i diskändan för att lättare kunna koppla loss kabeln när det är dags. Den kabeln kommer från en gammal 486:a som skulle köras till tippen, tror jag. Vid sin PC har min kompis en liten vagga där disken kan skjutas in i. Därefter skjuts hela vaggan in i en ram som sitter i datorn (STÄNG AV DATORN FÖRST). Inne i datorn är ramen kopplad till en ledig IDE kontakt. Ramen och vaggan går att köpa hos alla välsorterade PC butiker. Efter omstart är det GetHAV som gäller. När det är klart, det tar några timmar om disken är helt full, så stänger han datorn, tar ut vaggan, tar ut disken, kopplar disken till IDE kabeln i boxen plus strömkabel, lägger disken på vaggan med bena i bussningarna, lägger på kåpan, och till slut sätter på boxen. Hela proceduren körs ungefär en gång per kvartal. Vilken intelligent kompis jag har

Han kommer naturligtvis byta box så fort han hittar en med ungefär samma egenskaper som Dilog men med smidigare sätt att överföra filer, hör du Martin? Nätverk, helst trådlös, och SMB, och helst skrivning/läsning direkt på SMB disken, tack. Titta på Dreambox, gör samma men bättre och utan möjlighet att dela kortet över WAN.

/Mikael

Mycket åsikter om var felen ligger, vem som bär skulden och vem som skall åtgärda, så det är väl lika bra jag bidrar med mina åsikter också.

USB Downloader är såvitt känt skrivet av Finepass. Dilog har (hoppas jag) fått tillstånd att distribuera binären, men därmed inte sagt att man har tillgång till källkoden, än mindre rätt att släppa den publikt. Däremot har Finepass såvitt jag vet inget med GetHav att göra och har heller aldrig supportat detta program, det verkade vara ett hemmabygge och forumet i fråga drevs inte av Finepass.

Det är heller inte helt givet att Dilog har tillgång till protokollet på USB-porten, och även om de har så är det inte troligt att kontraktet med Handan tillåter att informationen görs publik. Hade det varit fritt fram så hade informationen sannolikt funnits ute med tanke på hur många tillverkare det finns av Handan-kloner. (Som jag ser det är det inte ens givet att Dilog har tillgång till komplett källkod, för Handan vore det troligen ganska lockande att tillhandahålla färdigkompilerade bibliotek, för filhantering och USB-protokoll exempelvis, och bara publicera ett API till kunderna)

Det jag vill ha sagt är att det är inte säkert Dilog själva kan göra så mycket åt situationen, förmodligen är det ingen i denna tråd som vet exakt vilka möjligheter de har att fixa firmware eller USB Downloader. Och utan att grundligt ha analyserat diskformatet och/eller trafiken på USB kan vi heller inte säkert peka ut var det går snett när en överförd fil blir korrupt, även om jag själv hade satt en slant på att det är USB Downloader som inte använder tillgänglig information på rätt sätt. Själva analysen kräver egentligen ingen programmeringskunskap, däremot brukar det underlätta om man har lite kunskap om hur likartade system är uppbyggda, och även då kan det ta mycket tid. De som redan ägnat tid åt diskformatet verkar än så länge valt att inte publicera sina rön, men med det borde gå att få fram en del så att man slipper starta från scratch.

Angående hastigheten på USB 1.1 så är det en stor världsomspännande konspiration (nåja) från tillverkarhåll att tala om 12 Mbit/s. Den siffran är bittakten i det elektriska snittet, men eftersom man med USB är hänvisad till åtskilliga lager med olika lösningar (halv duplex, bit stuffing, datapaket med synk och checksumma, kontrollsignalering o s v) så är det helt omöjligt att komma upp i denna siffra oavsett hur snabb hårdvara man har och hur väl koden är skriven. Varje lager i protokollet naggar lite på den totala kapaciteten, och i praktiken finns alltid vissa svarstider i både host och client. Den krets från Philips du hänvisar till är dessutom specificerad till att ge max 1 MB/s i bulk mode, alltså 8 Mbit/s. Tyvärr har jag inte riktigt lyckats utröna hur mycket overhead som är inräknat i detta värde, men jag tror även denna hastghet är omöjlig att uppnå i praktiken. Skulle jag gissa så är det utformningen av Handans protokoll som är främsta orsaken till att man inte når längre än ungefär 4 Mbit/s (enligt uppgift på detta forum), men med lite dålig kodning så kan USB Downloader definitivt också vara en flaskhals.

USB2-moddningen är som påpekat ett riktigt fulhack rent hårdvarumässigt, två controllers anslutna till samma kabel är en för mycket. Rent elektriskt brukar prylarna vara ganska stryktåliga, risken att hårdvaran går sönder är nog inte så stor, men däremot bedömer jag att risken i viss mån ökar för stabilitetsproblem och dataförlust. Ett mer seriöst alternativ vore väl en hårddiskvagga så att man enkelt flyttar disken mellan box och dator, dock föga tilltalande rent estetiskt och det kan kräva lite pyssel med kylning som då riskerar att öka ljudnivån. Garanti? Skulle inte tro det va.

Inget program får den – programmen får läsa den själva – vilket alltså USB Downloader inte gör (om det är den Downloader delen som finns på PC eller dess motpart i boxen går inte att säga). Däremot gör programvaran som spelar filer i boxen det bevisligen. Det är helt enkelt två olika programslingor som gör olika saker även när de hämtar data från disken.

Har påpekat för Dilog att det naturliga vore att alltid anropa samma rutin vid läsning oavsett om det sker "inuti boxen" eller på USB:n... men den data vi pratar om kommer ju ut igenom USB-anslutningen så USB Downloader borde ju kunna göra sig nytta av den. Att den inte gör det får väl tolkas som att det är den där "onödiga" läsrutinen inte kan göra sig nytta av denna information.

Martin är en trevlig karl att ha att göra med. Men hans ”rörelsefrihet” är begränsad av att han jobbar på ett företag. Jag har själv varit i sådana lägen där man internt är emot vissa beslut eller lösningar men utåt måste försvara företagets linje. Det är tufft men så länge man inte behöver göra våld på sina moraliska värderingar så går det ju, åtminstone då och då.

Jag kan knappt bärga mig i väntan på den fantastiska 1.19 uppdateringen 

Återstår ju att se hur fantastisk den är, men med tanke på att de flesta buggarna i kategorin "showstoppers" för dagligt bruk nu är borta, så känns det väl inte helt osannolikt att "bonusfunktionerna" (typ redigering o dyl) har fått sig en uppfräschning. Om detta gäller USB:n återstår väl att se. Återigen, bara gissningar...

Men Martin nämnde iallafall (någon månad innan 1.18 släpptes officiellt) att man periodvis då arbetade dygnet runt med den nya versionen - alltså inte 1.18 för när den släpptes officiellt så visade det sig vara samma version som dom skickade ut på mail även tidigare. Då 1.18 släpptes hade Dilog redan jobbat för högtryck på 1.19 i minst tre månader. Det är ju ett gott tecken, förhoppningsvis.

Det var du, inte jag, som sade att den (eller snarare drivern i XP) är en mass storage class. Jag påpekade bara att mass storage är en sak och filsystem är en annan.

Hoppsan... Nej drivrutinen har definitivt inget med Mass Storage class att göra, då hade den betett sig som jag beskrev ovan ( = visat sig som en flyttbar hårddisk i XP men inte varit tillgänglig pga filsystemet). Jag tror det är så att man slänger in en slags firmware i D12-chipet för att bestämma vilken typ av kontroller den blir. Det eller så bestäms det av boxens egen firmware... oavsett så borde det vara det önskvära beteendet - då skulle man ju t.ex inte behöva någon protokolldefinition, "bara" en portningsbar filsystemsdrivare baserad på den som redan implementerats i GetHAV.

Ja, Dilog verkar vara den enda boxen på marknaden vid sidan om Dreambox som har officiellt stöd för detta med USB överföring (eller någon överföring överhuvudtaget). Det är också den främsta anledningen till att jag valde Dilog. Det måste finnas möjligheter att använda DVR (PVR) på samma sätt som man använde VCR. Då lade man banden på hög, nu lägger man diskar eller skivor på hög. Jag kommer aldrig att skaffa en DVR utan den möjligheten. Tillverkarnas ovilja till att implementera detta går inte att begripa. BTW, Dreambox kan lagra filer direkt på en nätverksdisk med ett vanligt filsystem i ett standardiserat och väldokumenterat format så att man slipper att överföra dessa någonstans.

Hade Dreambox bara varit Boxer-godkänd så hade valet varit självklart (men då självklart en modell med inbyggd hårddisk så man slipper ha igång datorn jämt). Men just nu känns det som om Dilog är det enda alternativet om man inte vill slänga ut en förmögenhet på att bygga en HTPC (som ju kan bli betydligt mer än en digitalbox) som ändå kommer att krångla (och låta) bra mycket mer än Dilog:en.

Nej naturligtvis använder jag inte moddningen. Jag har funderat på vad det skulle innebära att implemetera den på det rätta sättet. Det är för mycket jobb för den lilla vinsten man gör. Jag har beskrivit hur min kompis gör. Han har dessutom underlättat det för sig på följande sätt.

8<--- klippt...

Han kommer naturligtvis byta box så fort han hittar en med ungefär samma egenskaper som Dilog men med smidigare sätt att överföra filer, hör du Martin? Nätverk, helst trådlös, och SMB, och helst skrivning/läsning direkt på SMB disken, tack.

<{POST_SNAPBACK}>

Backuplösningen är kanske inte helt så smidigt som man skulle kunna önska, men det fungerar väl om man inte spelar in så mycket. För min del är överföringen mer en typ av dagligt underhåll som jag inte skulle vilja göra med så långa tidsmellanrum (därav nödvändigheten att få USB Downloader och/eller filsystemet fixat). Min påtänkta hårddiskvagga är iallafall USB2 (har inte någon ledig 5.25" plats) så jag skulle inte behöva stänga av datorn för att plugga in disken. Däremot för att ta bort den skulle nog det kännas tryggast. Men jag får väl först se vad Martin säger, jag hoppas han kan erbjuda en bättre lösning ( = en fixad USB Downloader som fattar boxens "sekundära" struktur som du säger finns där inuti HAV-filerna). Hur som helst verkar det ju som om jag måste nollställa hårddisken efter det för att fixa det "primära" filsystemet.

Titta på Dreambox, gör samma men bättre och utan möjlighet att dela kortet över WAN.

... och få den nya boxen godkänd av Boxer. Det är den knepiga biten...
Hur som helst gör ju Dilog ingen egen hårdvara, så om inte Handan fixar biffen eller Dilog får lov att anpassa Dreambox för Boxer-godkännande, så kommer det nog inte att hända.

Redigerat av DVBgeek, 04 december 2006 - 22:27.

Mycket åsikter om var felen ligger, vem som bär skulden och vem som skall åtgärda, så det är väl lika bra jag bidrar med mina åsikter också.

USB Downloader är såvitt känt skrivet av Finepass. Dilog har (hoppas jag) fått tillstånd att distribuera binären, men därmed inte sagt att man har tillgång till källkoden, än mindre rätt att släppa den publikt. Däremot har Finepass såvitt jag vet inget med GetHav att göra och har heller aldrig supportat detta program, det verkade vara ett hemmabygge och forumet i fråga drevs inte av Finepass.

Det är heller inte helt givet att Dilog har tillgång till protokollet på USB-porten, och även om de har så är det inte troligt att kontraktet med Handan tillåter att informationen görs publik. Hade det varit fritt fram så hade informationen sannolikt funnits ute med tanke på hur många tillverkare det finns av Handan-kloner. (Som jag ser det är det inte ens givet att Dilog har tillgång till komplett källkod, för Handan vore det troligen ganska lockande att tillhandahålla färdigkompilerade bibliotek, för filhantering och USB-protokoll exempelvis, och bara publicera ett API till kunderna)

Det jag vill ha sagt är att det är inte säkert Dilog själva kan göra så mycket åt situationen, förmodligen är det ingen i denna tråd som vet exakt vilka möjligheter de har att fixa firmware eller USB Downloader. Och utan att grundligt ha analyserat diskformatet och/eller trafiken på USB kan vi heller inte säkert peka ut var det går snett när en överförd fil blir korrupt, även om jag själv hade satt en slant på att det är USB Downloader som inte använder tillgänglig information på rätt sätt. Själva analysen kräver egentligen ingen programmeringskunskap, däremot brukar det underlätta om man har lite kunskap om hur likartade system är uppbyggda, och även då kan det ta mycket tid. De som redan ägnat tid åt diskformatet verkar än så länge valt att inte publicera sina rön, men med det borde gå att få fram en del så att man slipper starta från scratch.

Angående hastigheten på USB 1.1 så är det en stor världsomspännande konspiration (nåja) från tillverkarhåll att tala om 12 Mbit/s. Den siffran är bittakten i det elektriska snittet, men eftersom man med USB är hänvisad till åtskilliga lager med olika lösningar (halv duplex, bit stuffing, datapaket med synk och checksumma, kontrollsignalering o s v) så är det helt omöjligt att komma upp i denna siffra oavsett hur snabb hårdvara man har och hur väl koden är skriven. Varje lager i protokollet naggar lite på den totala kapaciteten, och i praktiken finns alltid vissa svarstider i både host och client. Den krets från Philips du hänvisar till är dessutom specificerad till att ge max 1 MB/s i bulk mode, alltså 8 Mbit/s. Tyvärr har jag inte riktigt lyckats utröna hur mycket overhead som är inräknat i detta värde, men jag tror även denna hastghet är omöjlig att uppnå i praktiken. Skulle jag gissa så är det utformningen av Handans protokoll som är främsta orsaken till att man inte når längre än ungefär 4 Mbit/s (enligt uppgift på detta forum), men med lite dålig kodning så kan USB Downloader definitivt också vara en flaskhals.

USB2-moddningen är som påpekat ett riktigt fulhack rent hårdvarumässigt, två controllers anslutna till samma kabel är en för mycket. Rent elektriskt brukar prylarna vara ganska stryktåliga, risken att hårdvaran går sönder är nog inte så stor, men däremot bedömer jag att risken i viss mån ökar för stabilitetsproblem och dataförlust. Ett mer seriöst alternativ vore väl en hårddiskvagga så att man enkelt flyttar disken mellan box och dator, dock föga tilltalande rent estetiskt och det kan kräva lite pyssel med kylning som då riskerar att öka ljudnivån. Garanti? Skulle inte tro det va.

<{POST_SNAPBACK}>

Alla med åsikter är välkomna, tycker jag. Det är ju det man har ett forum för. Gillar man det skrivna ordet så är det inte bara sakfrågan utan även själva skrivandet, uttryckandet, och ”åsiktandet” som är poängen. Eftersom det är DVBgeek som startade tråden så får han agera t.f. moderator.

Håller till 100% med ditt inlägg. Några kommentarer bara.

GetHAV är skriven av en tysk entusiast för att rädda vad som räddas kunde när en Finepass programvaruuppdatering lämnade kaos efter sig på disken. Det är också han som gjorde det största jobbet med RE av filsystemet och av hav-formatet – det jobbet är långt ifrån klart. Han fick naturligtvis hjälp av andra entusiaster inklusive mig själv dock i mindre omfattning. GetHAV är fritt att användas för icke-kommersiellt bruk men det är inte en ”open-source” programvara. Jag försökte få författaren att lägga ut GetHAV som ett SourceForge projekt (och därmed open-source) men han gick inte med på detta. Även om jag inte håller med hans bevekelsegrunder måste jag respektera hans vilja. GetHAV klarar av att rädda många filer som USB Downloader går bet på dock inte alla.

Angående USB Download protokollet mm (som jag inte har en ringaste om) så förstår jag inte på vilket sätt kan hemlighållande av detta öka intäkter för Handan eller Dilog mm. Hade jag förstått detta då hade jag varit mindre kritiskt. Tvärtom tror jag att öppenhet skulle öka antalet sålda enheter eftersom då kunde andra bidra med programvara som vissa kunder kunde finna intressant. Samma gäller filsystem och hav-format. Vilken doktorand som helst på TDB, Datalogi mm kan designa minst lika bra filsystem om inte bättre. Det är 2006 nu, inte 1960. Så vadan detta hemlighetsmakeri? Skäms de över hur dåligt det är eller?

Ja, det är nog svårt att öka USB Downloader hastighet till att mäta sig med USB 2.0, Firewire eller ATA/IDE. Kanske skulle det gå att dubbla men det blir fortfarande olidligt långsamt. En bra DVB sändning går med 8 Mbit/s så även om man ökar USB Downloader till det dubbla mot nu så får man bara realtid. Det är alldeles för långsamt att köra över 30 stycken 2 – 3 timmars program när disken blir full.

Jag har också funderat på en vagga vid boxen. Men jag får problem med detta. Om det är en IDE vagga med IDE ut till boxen då blir det nästan lika jobbigt som den ovan beskrivna metoden. Något snyggare konceptuellt men i praktiken mer störande. Om man tänker sig en USB vagga med USB ut då behövs det fortfarande något som agerar en USB kontroller och omvandlar detta till IDE fast åt andra hållet så att säga, IDE till boxen inte till disken. Någon entusiast som vill konstruera en USB(disk)-till-IDE(dator) grej? De som går att köpa är ju IDE(disk)-till-USB(dator).

Jag tror att den här boxen får leva som den är tills den blir utkonkurrerat av något bättre, osagt från vilken tillverkare. Sedan finns det säkert många kunder som inte vill spara något utan bara simulera ”on-demand” med en inspelning och en timeshift samtidigt – men då får Handlog eller Didan se till att det funkar felfritt, alltid, i alla kombinationer utan att familjen behöver vara försiktig när de trycker på knappar. Det är ett vardagsrum och inte ett lab vi pratar om.

/Mikael

Har påpekat för Dilog att det naturliga vore att alltid anropa samma rutin vid läsning oavsett om det sker "inuti boxen" eller på USB:n... men den data vi pratar om kommer ju ut igenom USB-anslutningen så USB Downloader borde ju kunna göra sig nytta av den. Att den inte gör det får väl tolkas som att det är den där "onödiga" läsrutinen inte kan göra sig nytta av denna information.

Eller att den inte finns helt enkelt...

Hoppsan... smile.gif Nej drivrutinen har definitivt inget med Mass Storage class att göra, då hade den betett sig som jag beskrev ovan ( = visat sig som en flyttbar hårddisk i XP men inte varit tillgänglig pga filsystemet). Jag tror det är så att man slänger in en slags firmware i D12-chipet för att bestämma vilken typ av kontroller den blir. Det eller så bestäms det av boxens egen firmware... oavsett så borde det vara det önskvära beteendet - då skulle man ju t.ex inte behöva någon protokolldefinition, "bara" en portningsbar filsystemsdrivare baserad på den som redan implementerats i GetHAV.

Du går lite fort här från chipet till XP’s flyttbara diskar... men vi struntar i det.

Backuplösningen är kanske inte helt så smidigt som man skulle kunna önska, men det fungerar väl om man inte spelar in så mycket. För min del är överföringen mer en typ av dagligt underhåll som jag inte skulle vilja göra med så långa tidsmellanrum (därav nödvändigheten att få USB Downloader och/eller filsystemet fixat). Min påtänkta hårddiskvagga är iallafall USB2 (har inte någon ledig 5.25" plats) så jag skulle inte behöva stänga av datorn för att plugga in disken. Däremot för att ta bort den skulle nog det kännas tryggast. Men jag får väl först se vad Martin säger, jag hoppas han kan erbjuda en bättre lösning ( = en fixad USB Downloader som fattar boxens "sekundära" struktur som du säger finns där inuti HAV-filerna). Hur som helst verkar det ju som om jag måste nollställa hårddisken efter det för att fixa det "primära" filsystemet.

Det kan ju vara så att USB Downloader fattar den sekundära men inte den primära också. Man vet inte förrän man vet.

Hade jag inte en gammal 5.25’’ IDE vagga som inte gjorde någon nytta då hade jag behövt lägga ut pengar för en ny USB2 också.

Titta på Dreambox, gör samma men bättre och utan möjlighet att dela kortet över WAN.

... och få den nya boxen godkänd av Boxer. Det är den knepiga biten...

Det är nog den där kortdelningen som är problemet för Boxer, och det kan man ju förstå.

Hur som helst gör ju Dilog ingen egen hårdvara, så om inte Handan fixar biffen eller Dilog får lov att anpassa Dreambox för Boxer-godkännande, så kommer det nog inte att hända.

De kan ju alltid börja, jag menade inte att de skall anpassa Dreambox, bara studera den. Eftersom den är open-source då måste den förbli det även efter en anpassning om man skall följa licensvillkoren. Och då blir det genast svårare att spärra det man vill spärra. Den där kniven skär åt båda hållen så att säga.

/Mikael

Angående USB Download protokollet mm (som jag inte har en ringaste om) så förstår jag inte på vilket sätt kan hemlighållande av detta öka intäkter för Handan eller Dilog mm. Hade jag förstått detta då hade jag varit mindre kritiskt. Tvärtom tror jag att öppenhet skulle öka antalet sålda enheter eftersom då kunde andra bidra med programvara som vissa kunder kunde finna intressant. Samma gäller filsystem och hav-format. Vilken doktorand som helst på TDB, Datalogi mm kan designa minst lika bra filsystem om inte bättre. Det är 2006 nu, inte 1960. Så vadan detta hemlighetsmakeri? Skäms de över hur dåligt det är eller?

Ja, det är nog svårt att öka USB Downloader hastighet till att mäta sig med USB 2.0, Firewire eller ATA/IDE. Kanske skulle det gå att dubbla men det blir fortfarande olidligt långsamt. En bra DVB sändning går med 8 Mbit/s så även om man ökar USB Downloader till det dubbla mot nu så får man bara realtid. Det är alldeles för långsamt att köra över 30 stycken 2 – 3 timmars program när disken blir full.

/snip/

Jag tror att den här boxen får leva som den är tills den blir utkonkurrerat av något bättre, osagt från vilken tillverkare. Sedan finns det säkert många kunder som inte vill spara något utan bara simulera ”on-demand” med en inspelning och en timeshift samtidigt – men då får Handlog eller Didan se till att det funkar felfritt, alltid, i alla kombinationer utan att familjen behöver vara försiktig när de trycker på knappar. Det är ett vardagsrum och inte ett lab vi pratar om.

/Mikael

<{POST_SNAPBACK}>

Nej, jag kan heller inte se något skäl att hemlighålla själva specifikationerna för protokoll eller filsystem, det innehåller knappast något som skadar Handan om det kommer i allmänhetens händer. Det är dock inget beslut som ligger hos Dilog, som kanske inte ens själva har tillgång till dessa specifikationer. Däremot kan jag se en poäng för Handan att inte låta alla licenstagare härja runt var de vill i källkoden, därav min kommentar om att de kanske delvis gjorde sin egen implementation tillgänglig i kompilerad form, vilket alltså i sig inte skulle hindra att specifikationen släpptes. Att andra skulle kunna göra ett lika bra filsystem betvivlar jag inte, frågan är väl om man i en så begränsad applikation som en digitalbox egentligen behöver ett bättre filsystem? Visst, det verkar finnas en minnesläcka nånstans som gör att raderingar kan hänga sig, vilket uppenbart påverkar filsystemet i någon mån. Men det handlar då om en bugg i mjukvaran, alla filsystem kan påverkas av att mjukvaran hänger, men filsystemet i sig behöver inte vara en undermålig konstruktion för det.

Med USB 1.1 kan det som sagt knappast bli frågan om annat än överföring av enstaka program, åtminstone för mig, oavsett om man lyckas pressa upp hastigheten till max vad som hårdvaran klarar.

Redan när jag köpte boxen för ca 9 månader sedan så var det med tanken att den skulle vara ett provisorium att användas 1-1,5 år. Jag såg att det började dyka upp riktigt intressanta boxar från många tillverkare och räknade med att det under 2007 skulle finnas ett bra utbud med exakt de funktioner jag eftersökte (och samtidigt kunde jag komma underfund med vad jag egentligen ville ha ut av en box, vilket har varit nyttigt). Under tiden skulle Dilogen hinna stabilisera sig såpass att jag skulle våga sätta den i händerna på föräldrarna lagom till dess att det analoga nätet släcks här. Vi är väl inte riktigt där ännu, men det tar sig så sakteliga, både vad gäller utbud av andra boxar och denna boxens pålitlighet. Samtidigt är detta ett av skälen att jag inte kommer att lägga någon större energi på reverse enginering av USB-protokollet. I dagsläget börjar det bli dags att tömma disken en första gång, troligen den enda gången innan jag gör flyttstädning inför byte till annan box. Det är inte mödan värt att jobba så hårt för att slippa lyfta ur disken vid två tillfällen, då har jag andra liknande obetalda (och tyvärr försummade) fritidssysslor som jag måste prioritera betydligt högre.

USB Downloader är såvitt känt skrivet av Finepass.

Inte enligt programmet självt (det är "signerat" av Handan BroadInfo) och även den halvdåliga engelskan i programmet ger intrycket att det inte är av europeiskt ursprung.

(Som jag ser det är det inte ens givet att Dilog har tillgång till komplett källkod, för Handan vore det troligen ganska lockande att tillhandahålla färdigkompilerade bibliotek, för filhantering och USB-protokoll exempelvis, och bara publicera ett API till kunderna)

Tja, den respons som vi hittils har fått från Martin på Dilog verkar ju antyda att dom faktiskt programmerar i firmwaren själva.

Det jag vill ha sagt är att det är inte säkert Dilog själva kan göra så mycket åt situationen, förmodligen är det ingen i denna tråd som vet exakt vilka möjligheter de har att fixa firmware eller USB Downloader.

Nä, det vet nog bara dom på Dilog. Beroende på hur stora förbättringar som gjorts i 1.19 så kanske det blir tydligare vem som gör ändringarna - vid det här laget kan vi ju konstatera att Handan inte kan tillhandahålla felfri kod så man får anta att fungerande fixar kommer från klontillverkarna.

Angående USB Download protokollet mm (som jag inte har en ringaste om) så förstår jag inte på vilket sätt kan hemlighållande av detta öka intäkter för Handan eller Dilog mm. Hade jag förstått detta då hade jag varit mindre kritiskt. Tvärtom tror jag att öppenhet skulle öka antalet sålda enheter eftersom då kunde andra bidra med programvara som vissa kunder kunde finna intressant. Samma gäller filsystem och hav-format. Vilken doktorand som helst på TDB, Datalogi mm kan designa minst lika bra filsystem om inte bättre. Det är 2006 nu, inte 1960. Så vadan detta hemlighetsmakeri? Skäms de över hur dåligt det är eller?

Ja, det är nog svårt att öka USB Downloader hastighet till att mäta sig med USB 2.0, Firewire eller ATA/IDE. Kanske skulle det gå att dubbla men det blir fortfarande olidligt långsamt. En bra DVB sändning går med 8 Mbit/s så även om man ökar USB Downloader till det dubbla mot nu så får man bara realtid. Det är alldeles för långsamt att köra över 30 stycken 2 – 3 timmars program när disken blir full.

Man tycker ju att dom vid det här laget borde ha insett att Handans filsystem lämnar mycket övrigt att önska i fråga om stabilitet, funktionalitet och kompatibilitet. Kan man kasta ut det och istället köra med ett väldokumenterat och beprövat filsystem (men inte fat32 pga filstorleksbegränsningen) vore det ju högst önskvärt.

Jag har efterfrågat en möjlighet att lägga USB-överföringen i "bakgrunden" så att den inte stör inspelnings- och timeshiftmöjligheter. Om jag minns rätt så klarade faktiskt boxen att timeshifta under överföring i firmware 1.17, eller också var det bara slumpen som gjorde att det funkade en gång, men det visar ju iallafall att boxen klarar det rent hårdvarumässigt. Det finns också många andra exempel på "simultanförmågor" som boxen klarar om man ser till hårdvaran men som Dilog eller Handan valt att endast göra tillgänliga var för sig istället för samtidigt - man får väl anta att det till en stor del beror på att mjukvaran inte är särskilt väl optimerad...

Jag tror att den här boxen får leva som den är tills den blir utkonkurrerat av något bättre, osagt från vilken tillverkare. Sedan finns det säkert många kunder som inte vill spara något utan bara simulera ”on-demand” med en inspelning och en timeshift samtidigt – men då får Handlog eller Didan se till att det funkar felfritt, alltid, i alla kombinationer utan att familjen behöver vara försiktig när de trycker på knappar. Det är ett vardagsrum och inte ett lab vi pratar om.

<{POST_SNAPBACK}>

Exakt, även om vi som har stort intresse för datorer och liknande prylar ju klarar av att hantera boxen hjälpligt även när den krånglar, så är det ju inte alla av oss som har familjer med samma nivå av kunskap/erfarenhet inom detta område. Jag anser att kravet på en bra box är att den 1) är lättanvänd och felsäker för dagligt bruk av icke-tekniska personer, och 2) att den har en bra uppsättning extra funktioner (t.ex för backup) som passar för erfarna/avancerade användare.

Att andra skulle kunna göra ett lika bra filsystem betvivlar jag inte, frågan är väl om man i en så begränsad applikation som en digitalbox egentligen behöver ett bättre filsystem? Visst, det verkar finnas en minnesläcka nånstans som gör att raderingar kan hänga sig, vilket uppenbart påverkar filsystemet i någon mån. Men det handlar då om en bugg i mjukvaran, alla filsystem kan påverkas av att mjukvaran hänger, men filsystemet i sig behöver inte vara en undermålig konstruktion för det.

I en dator hade jag kunnat stå ut med ett undermåligt filsystem ett tag, eftersom det A) är lättare att uppgradera och det finns många filsystem att välja på och man kan ju byta operativsystem om man vill kunna använda ett annat filsystem. I vissa operativsystem (XP, Linux/BSD...) kan man ju även installera extra filsystemsmoduler i efterhand.
I en digitalbox eller DVD-inspelare t.ex har man inte dessa möjligheter och därför måste det ställas mycket högre krav på filsystem och mjukvara i dessa enheter. En digitalbox bör vara helt stabil när den släpps på marknaden och utveckling därefter läggas på t.ex nya funktioner eller att optimera befintliga, men några buggar får absolut inte finnas i så viktiga delar av systemet som filsystem eller backuprutiner, i synnerhet inte av så stor magnitud som de buggar vi diskuterar i denna tråd. Hela konceptet med hårddiskbox faller liksom ganska platt ifall man inte kan lita på att just DVR-funktionerna fungerar klockrent...

Med USB 1.1 kan det som sagt knappast bli frågan om annat än överföring av enstaka program, åtminstone för mig, oavsett om man lyckas pressa upp hastigheten till max vad som hårdvaran klarar.

Om man lyckas få USB-överföringen att inte störa boxens övriga DVR-funktioner (inspelning, uppspelning, timeshift, avkodning) så skulle jag inte ha något emot att köra med den nuvarande hastigheten. Lyckas man dessutom öka througput så att ett program från SVT (det brukar vara dom som använder 8Mbit/s eller mer) kan överföras i realtid så anser jag att boxen nått upp till sin högsta potential i detta avseende.

Under tiden skulle Dilogen hinna stabilisera sig såpass att jag skulle våga sätta den i händerna på föräldrarna lagom till dess att det analoga nätet släcks här. Vi är väl inte riktigt där ännu, men det tar sig så sakteliga, både vad gäller utbud av andra boxar och denna boxens pålitlighet.

<{POST_SNAPBACK}>

Så sant, och jag hoppas också att det finns betydligt bättre Boxer-godkända boxar med överföringsmöjlighet när det analoga nätet släcks ner i mitt område. Men eftersom Dilogen kostade så mycket så tänker jag också hålla fast vid den ett bra tag. Dilog säger åtminstone att man inte kommer att sluta utveckla firmware till DT550 förrän den är felfri, så man får väl hoppas att dom står vid sitt ord.

Redigerat av DVBgeek, 05 december 2006 - 12:03.

Att andra skulle kunna göra ett lika bra filsystem betvivlar jag inte, frågan är väl om man i en så begränsad applikation som en digitalbox egentligen behöver ett bättre filsystem? Visst, det verkar finnas en minnesläcka nånstans som gör att raderingar kan hänga sig, vilket uppenbart påverkar filsystemet i någon mån. Men det handlar då om en bugg i mjukvaran, alla filsystem kan påverkas av att mjukvaran hänger, men filsystemet i sig behöver inte vara en undermålig konstruktion för det.

Nej visst, de flesta filsystem består av ganska enkla datastrukturer. Det är programvaran för åtkomst till dessa datastrukturer från andra högre nivå programvaror som är avgörande. Så länge datorn gör en enda sak i taget är detta trivialt. Så fort som datorn gör 2 eller fler saker samtidigt blir detta till ett mycket avancerat projekt. Till exempel när 2 filer skall skrivas samtidigt (timeshift och inspelning) varav den första skall också läsas på ett annat ställe (timeshift). Jag tror att den ursprungliga Handan programvaran är inte gjord för detta med 2 receivrar. Man har lagt till den andra i efterhand men man orkade inte eller ville inte av kostnads- eller andra skäl skriva om programvaran till äkta fleruppdragskörning vilket är svårt. Istället har man i bästa klåparstill fixat och lappat för att få fram något som går att sälja. Till exempel har man försökt att ersätta köhantering för samtidigt diskåtkomst med att allokera en fix area för hela timeshiften när den startar för att på det sättet slippa ta hänsyn till detta när den vanliga inspelningen går samtidigt. Därav den fixa tiden för timeshift och att även korta timeshift tar samma plats på disken som långa. Det fungerar om inspelningen startar före timeshift men inte så bra i omvänd ordning. Generellt kan man säga att om inte programvaran är från grunden designad för fleruppdragskörning så kommer det alltid att bli problem då och då och det hela kommer att bero på i viken sekvens man trycker på knapparna på fjärren och hur fort. Det finns inga genvägar där – kommer Ni ihåg DOS?

Jag kan förstå att det manöverutrymme som Dilog har visavi Handan är begränsat. Men som konsument är det Dilog som bär det hela tillverkaransvaret för mig. Har man valt att sälja produkten under sitt eget namn då har man också tagit över det ansvaret helt. Annars så skulle ju alla tillverkare kunna gömma sig bakom sina underleverantörer.

Till saken hör att de flesta av dagens boxtillverkare/leverantörer är borta inom några få år eller åtminstone sysslar med annat. När övergången till DVB är klar då sjunker ju efterfrågan på boxarna till kanske en tiondel av vad den är nu. Vad skall de leva av då? HD kommer att förlänga den agonin lite men den går inte att stoppa. Sedan kommer alla TV säljas med inbyggd DVB och då är det adjöss med boxarna. Precis som det var när TV2 kom.

Företagsmarknadsmässigt ligger dagens boxtillverkare/leverantörer i kategorin ”gerilla” (inget negativt i det ordet i det sammanhanget). Man tar vad man kan och försvinner. Det är en välkänd och accepterad företagsstrategi. Men den är inte speciellt bra för konsumenter. Det är kanske detta som är problemets kärna.

Det finns dock en riktning som det går att gå och som leder bortom övergången. Den heter HTPC. Där är det bara Dreambox (bland boxarna) som har den flexibilitet, grundläggande programvara (OS) och styrka som krävs.

/Mikael

I en dator hade jag kunnat stå ut med ett undermåligt filsystem ett tag, eftersom det A) är lättare att uppgradera och cool.gif det finns många filsystem att välja på och man kan ju byta operativsystem om man vill kunna använda ett annat filsystem. I vissa operativsystem (XP, Linux/BSD...) kan man ju även installera extra filsystemsmoduler i efterhand.
I en digitalbox eller DVD-inspelare t.ex har man inte dessa möjligheter och därför måste det ställas mycket högre krav på filsystem och mjukvara i dessa enheter. En digitalbox bör vara helt stabil när den släpps på marknaden och utveckling därefter läggas på t.ex nya funktioner eller att optimera befintliga, men några buggar får absolut inte finnas i så viktiga delar av systemet som filsystem eller backuprutiner, i synnerhet inte av så stor magnitud som de buggar vi diskuterar i denna tråd. Hela konceptet med hårddiskbox faller liksom ganska platt ifall man inte kan lita på att just DVR-funktionerna fungerar klockrent...

Precis, och dessutom använder man datorer i ett annat sammanhang än hemelektronik, åtminstone än så länge.

Så sant, och jag hoppas också att det finns betydligt bättre Boxer-godkända boxar med överföringsmöjlighet när det analoga nätet släcks ner i mitt område. Men eftersom Dilogen kostade så mycket så tänker jag också hålla fast vid den ett bra tag. Dilog säger åtminstone att man inte kommer att sluta utveckla firmware till DT550 förrän den är felfri, så man får väl hoppas att dom står vid sitt ord.

Det där med Boxer-godkännande gör ju varken till eller från, som Dilogs (och de andra boxarnas) kvalitet (eller snarare brist på) visar. Alla dagens boxar, godkända eller ej, fungerar alldeles utmärkt i de aspekter som Boxers officiella godkännande kräver/testar. Det enda som godkännandeprocessen gör idag är att det fördyrar boxarna. Det finns inte heller några formella krav på att de boxar som säljs skulle vara godkända. Därför kommer det så småningom att försvinna av sig själv – precis som det gamla Televerkets godkännande av modem försvann – på slutet var de icke godkända mycket billigare och bättre.

Å andra sidan subventionerar Boxer vissa fabrikat och då väljer man naturligtvis bland de godkända boxarna och lägger då till vissa andra villkor som man talar tyst om av politiska eller andra skäl. Denna hysch hysch gör ju att man får en uppfattning att någonting inte är riktigt rätt där annars skulle man ju inte behöva hyscha. Och saken blir inte bättre av Boxers senaste eskapader i Marknadsdomstolen och i EU.

/Mikael

USB Downloader är såvitt känt skrivet av Finepass.

Inte enligt programmet självt (det är "signerat" av Handan BroadInfo) och även den halvdåliga engelskan i programmet ger intrycket att det inte är av europeiskt ursprung.

Halvdålig engelska kan ju också uppträda i program skrivna i Tyskland. Att Finepass har något med USB Downloader att göra baserar jag på att deras namn finns i både installationsinformation och den exekverbara filen. Alla klontillverkare jag kollat hos använder samma program, TEAC kallar den till och med Finepass Transfer Software. Kan ju för all del vara så att Finepass bara översatt programmet och att ingen annan klontillverkare brytt sig om att göra några egna versioner utan bara valt att distribuera den.

I en dator hade jag kunnat stå ut med ett undermåligt filsystem ett tag, eftersom det A) är lättare att uppgradera och B) det finns många filsystem att välja på och man kan ju byta operativsystem om man vill kunna använda ett annat filsystem. I vissa operativsystem (XP, Linux/BSD...) kan man ju även installera extra filsystemsmoduler i efterhand.

Jag kanske skall förtydliga att med filsystem menar jag hur informationen är strukturerad på disken och vilka möjligheter det ger. Utan att ha analyserat detta kan jag inte se att det finns några belägg för att filsystemet skulle vara undermåligt, det kanske tvärtom är ytterst väl anpassat för uppgiften. Filsystemet på en PC måste kunna lösa ganska varierade uppgifter, men för en DVR-box där användningsmönstret är ganska snävt begränsat kan det vara en poäng med ett (enligt uppgift) enklare system som kanske dessutom optimerats för den specifika uppgiften. Färre finesser ger rimligen mindre risk att något går snett, och med tanke på att filsystemet uppenbarligen inte verkar balla ur fullständigt i samband med att boxen hänger sig (och gissningsvis inte heller vid strömavbrott) så är konstruktionen anständigt robust.

Jag kanske skall förtydliga att med filsystem menar jag hur informationen är strukturerad på disken och vilka möjligheter det ger. Utan att ha analyserat detta kan jag inte se att det finns några belägg för att filsystemet skulle vara undermåligt, det kanske tvärtom är ytterst väl anpassat för uppgiften. Filsystemet på en PC måste kunna lösa ganska varierade uppgifter, men för en DVR-box där användningsmönstret är ganska snävt begränsat kan det vara en poäng med ett (enligt uppgift) enklare system som kanske dessutom optimerats för den specifika uppgiften. Färre finesser ger rimligen mindre risk att något går snett, och med tanke på att filsystemet uppenbarligen inte verkar balla ur fullständigt i samband med att boxen hänger sig (och gissningsvis inte heller vid strömavbrott) så är konstruktionen anständigt robust.

<{POST_SNAPBACK}>

Vad vi så här långt tycks ha kommit fram till i den här tråden är ju just precis det att filsystemet i Dilogen faktiskt "ballar ur" just vid t.ex en hängd raderingsprocess. Att boxen sedan har "andra" sätt att själv gå runt detta hjälper ju föga när den inte sedan utnyttjar denna sekundära information för att fysiskt rätta till den primära informationen som blivit fel (á la fsck eller chkdsk). USB Downloader använder ju tydligen inte den "sekundära" informationen så antingen får man väl då modifiera USB Downloader till att faktiskt göra det, eller så får man trycka in en extra funktion i firmware som faktiskt inte bara utnyttjar den redundanta informationen vid uppspelning utan också skriver om den förstörda filtabellen baserat på detta så att USB Downloader får rätt information... och med tanke på det lilla utrymmet för firmware (om man inte lyckas göra en firmware som kan leta efter en "större" firmware på hårddisken vid boot) så tror jag en modifiering av USB Downloader vore det enklaste sättet att lösa problemet på. Det skulle ju ändå kräva att man förr eller senare formatterade om hårddisken från grunden för att få en korrekt primär filtabell igen, men om USB Downloader lär sig att fatta hela strukturen så kanske man också kan få en varning av den ifall den hittar inkonsekvent information mellan de olika tabellerna?

Halvdålig engelska kan ju också uppträda i program skrivna i Tyskland. Att Finepass har något med USB Downloader att göra baserar jag på att deras namn finns i både installationsinformation och den exekverbara filen. Alla klontillverkare jag kollat hos använder samma program, TEAC kallar den till och med Finepass Transfer Software. Kan ju för all del vara så att Finepass bara översatt programmet och att ingen annan klontillverkare brytt sig om att göra några egna versioner utan bara valt att distribuera den.

Kollar du egenskaperna och versionsinformationen (i Utforskaren) för programmet så är den signerad av Handan och även copyrightad till Handan... Finepass finns så sett endast i själva "översättningen" av programmet, så det kanske är så att Handan skrev programmet åt Finepass från början och att sedan andra tillverkare inte brytt sig om att sätta in sina egna märkesnamn i programmet?

Det finns dock en riktning som det går att gå och som leder bortom övergången. Den heter HTPC. Där är det bara Dreambox (bland boxarna) som har den flexibilitet, grundläggande programvara (OS) och styrka som krävs.

/Mikael

<{POST_SNAPBACK}>

Jämför man styrka så är egentligen den enda skillnaden mellan Dilog och Dreambox att Dilog har mindre minne. Tyvärr är det monterat direkt på moderkortet enligt Martin så det går inte att uppgradera. Men i övrigt så har Dilog definitivt styrkan att driva ett riktigt (men litet) operativsystem av samma typ som Dreambox (båda använder PowerPC av samma generation och hastighet). Sedan har ju Dreamboxen förstås även den stora fördelen att den har ett Ethernet-interface att köra en massa tillämpningar över (och även att därmed kunna spara på t.ex en SMB-server istället för den interna hårddisken) men det är ju inte många som har en server på hemma dygnet runt (än)...

Men även Handan-klonerna kan faktiskt driva externa tillbehör, även om det enda jag sett hittils drivs via serieporten och är en extern display för att visa mer info än den inbyggda displayen.

Redigerat av DVBgeek, 06 december 2006 - 10:31.

Jag kanske skall förtydliga att med filsystem menar jag hur informationen är strukturerad på disken och vilka möjligheter det ger. Utan att ha analyserat detta kan jag inte se att det finns några belägg för att filsystemet skulle vara undermåligt, det kanske tvärtom är ytterst väl anpassat för uppgiften. Filsystemet på en PC måste kunna lösa ganska varierade uppgifter, men för en DVR-box där användningsmönstret är ganska snävt begränsat kan det vara en poäng med ett (enligt uppgift) enklare system som kanske dessutom optimerats för den specifika uppgiften. Färre finesser ger rimligen mindre risk att något går snett, och med tanke på att filsystemet uppenbarligen inte verkar balla ur fullständigt i samband med att boxen hänger sig (och gissningsvis inte heller vid strömavbrott) så är konstruktionen anständigt robust.

<{POST_SNAPBACK}>

Vad vi så här långt tycks ha kommit fram till i den här tråden är ju just precis det att filsystemet i Dilogen faktiskt "ballar ur" just vid t.ex en hängd raderingsprocess. Att boxen sedan har "andra" sätt att själv gå runt detta hjälper ju föga när den inte sedan utnyttjar denna sekundära information för att fysiskt rätta till den primära informationen som blivit fel (á la fsck eller chkdsk). USB Downloader använder ju tydligen inte den "sekundära" informationen så antingen får man väl då modifiera USB Downloader till att faktiskt göra det, eller så får man trycka in en extra funktion i firmware som faktiskt inte bara utnyttjar den redundanta informationen vid uppspelning utan också skriver om den förstörda filtabellen baserat på detta så att USB Downloader får rätt information... och med tanke på det lilla utrymmet för firmware (om man inte lyckas göra en firmware som kan leta efter en "större" firmware på hårddisken vid boot) så tror jag en modifiering av USB Downloader vore det enklaste sättet att lösa problemet på. Det skulle ju ändå kräva att man förr eller senare formatterade om hårddisken från grunden för att få en korrekt primär filtabell igen, men om USB Downloader lär sig att fatta hela strukturen så kanske man också kan få en varning av den ifall den hittar inkonsekvent information mellan de olika tabellerna?

Nej, vi har inte kommit fram till någonting att tala om, och det kommer vi inte heller att göra förrän det görs en metodisk analys i stället för att gissa och dra ogrundade slutsatser om var felen ligger.

* Det är inte konstaterat att det blir mismatch mellan "primär" och "sekundär" information, ingen vet väl ens om det alls finns någon sådan koppling mellan dessa. Finns inte denna koppling kan heller inte USB Downloader avgöra om informationen är inkonsekvent, och boxen kan följaktligen heller inte använda den för att reparera eventuella fel.

* Det är inte konstaterat att den "sekundära" informationen har något med misslyckade filöverföringar att göra.

* Det är inte konstaterat vilka metoder USB Downloader använder, alltså vet vi inte om eller hur den använder den "sekundära" informationen. Det är inte ens konstaterat att USB Downloader har någon anledning att använda den "sekundära" informationen.

* Det är inte konstaterat att någon fil(allokerings)tabell blivit förstörd.

* Det är inte konstaterat att problemet kan lösas genom en modifiering av USB Downloader.

Allt som än så länge är belagt är att de filer som USB Downloader skriver ibland får fel innehåll. Det finns en lång räcka med tänkbara felkällor mellan hårddisken i boxen och hårddisken i PCn. Att utifrån denna enda säkra observation ställa diagnoser om vad som är fel eller hur enskilda länkar i kedjan beter sig och borde modifieras är inte meningsfullt.

Att en radering som hänger sig lämnar en viss oreda i filsystemet får anses belagt, filnamn blir osynliga i DVR-listan, men det är däremot inte belagt att det får några bestående effekter. Att det i förlängningen skulle ha något med misslyckade filöverföringar att göra är en helt obekräftad teori.

Det jag menar med att filsystemet inte "ballar ur" när en radering hänger sig är att alla filer man ville behålla fortfarande är intakta och tills motsatsen bevisats så fungerar boxen lika bra (eller dåligt om man så vill) som tidigare. Inga obehagliga överraskningar som att nya inspelningar skriver över gamla till exempel.

* Det är inte konstaterat att det blir mismatch mellan "primär" och "sekundär" information, ingen vet väl ens om det alls finns någon sådan koppling mellan dessa. Finns inte denna koppling kan heller inte USB Downloader avgöra om informationen är inkonsekvent, och boxen kan följaktligen heller inte använda den för att reparera eventuella fel.

* Det är inte konstaterat att den "sekundära" informationen har något med misslyckade filöverföringar att göra.

* Det är inte konstaterat vilka metoder USB Downloader använder, alltså vet vi inte om eller hur den använder den "sekundära" informationen. Det är inte ens konstaterat att USB Downloader har någon anledning att använda den "sekundära" informationen.

* Det är inte konstaterat att någon fil(allokerings)tabell blivit förstörd.

* Det är inte konstaterat att problemet kan lösas genom en modifiering av USB Downloader.

Allt är förstås mycket teoretiskt, eftersom Dilog själva inte bidragit med några insikter. Men det verkar som om mhakman har ganska god koll på filsystemet och han tycks ju dra de slutsatser jag summerade i mitt inlägg, iallfall.

Vad vi vet utifrån mhakmans observationer är ju iallafall att den sekundära strukturen finns med bland den data som förs över till datorn och sparas i filen, den ingår ju enligt honom i de "Handan-specifika headers" som finns spridda i filen som annars skulle vara en vanlig TS.

Om jag missuppfattat mhakmans slutsatser ber jag om ursäkt och vill gärna be honom summera vad vi kommit fram till så här långt.

Allt som än så länge är belagt är att de filer som USB Downloader skriver ibland får fel innehåll.

Vi kan väl vid det här laget även konstatera att den data som USB Downloader får ifrån boxen är fel eftersom man uppe i den riktiga strömmen hittar data från andra filer, till och med borttagna sådana. Om det beror på ett fel i boxen eller i USB Downloader återstår väl att se, men det är fullt möjligt att det inte är formellt fel på någon av "sidorna" utan endast ett förbiseende, en brist, i någondera mjukvara (firmware, drivrutin eller Downloader).

Att en radering som hänger sig lämnar en viss oreda i filsystemet får anses belagt, filnamn blir osynliga i DVR-listan, men det är däremot inte belagt att det får några bestående effekter. Att det i förlängningen skulle ha något med misslyckade filöverföringar att göra är en helt obekräftad teori.

Därmed dock inte sagt att den teorin är osannolik. Jag hade inga problem att föra över filer i början, det är något som kommit plötsligt (sedan firmware 1.18) och tidsmässigt hänger det samman med antingen denna uppgradering eller den första (och enda) radering som misslyckats på den här boxen.

Det jag menar med att filsystemet inte "ballar ur" när en radering hänger sig är att alla filer man ville behålla fortfarande är intakta och tills motsatsen bevisats så fungerar boxen lika bra (eller dåligt om man så vill) som tidigare. Inga obehagliga överraskningar som att nya inspelningar skriver över gamla till exempel.

<{POST_SNAPBACK}>

I praktiken är filerna inte intakta, eftersom man inte kan ta backup på dom och behålla dom intakta (inte med den "rätta" (officiella) metoden iallafall). Vid backup kan man därför råka ut för överraskningar som t.ex att en backup inte fungerar till mer än 50% därför att resten av filstorleken innehåller data från orelaterade och till och med raderade inspelningar. Huruvida detta beror på filsystemet är ju en annan sak.

Redigerat av DVBgeek, 06 december 2006 - 18:58.

Allt som än så länge är belagt är att de filer som USB Downloader skriver ibland får fel innehåll.

Vi kan väl vid det här laget även konstatera att den data som USB Downloader får ifrån boxen är fel eftersom man uppe i den riktiga strömmen hittar data från andra filer, till och med borttagna sådana. Om det beror på ett fel i boxen eller i USB Downloader återstår väl att se, men det är fullt möjligt att det inte är formellt fel på någon av "sidorna" utan endast ett förbiseende, en brist, i någondera mjukvara (firmware, drivrutin eller Downloader).

Visst kan man drömma ihop ett scenario där man skickar större sjok med data där sedan USB Downloader skall extrahera rätt information, men det vore ju både långsökt och korkat, alltså kan vi nog utgå från att det som kommer i USB-snöret är fel. Men som sagt, det kan finnas mängder med olika orsaker till att det skickas fel data.

Att en radering som hänger sig lämnar en viss oreda i filsystemet får anses belagt, filnamn blir osynliga i DVR-listan, men det är däremot inte belagt att det får några bestående effekter. Att det i förlängningen skulle ha något med misslyckade filöverföringar att göra är en helt obekräftad teori.

Därmed dock inte sagt att den teorin är osannolik. Jag hade inga problem att föra över filer i början, det är något som kommit plötsligt (sedan firmware 1.18) och tidsmässigt hänger det samman med antingen denna uppgradering eller den första (och enda) radering som misslyckats på den här boxen.

Likafullt en obekräftad teori så här långt. Ärligt talat tycker jag att det finns en sak som talar emot den teorin. Om man skriver sönder en tabell på så sätt att en läsning av filer går snett, så borde den även samtidigt ta sönder den på så sätt att nya filer skriver över gamla, och det händer av allt att döma inte. Detta skrivet utan nödvändig kunskap om hur just detta filsystem fungerar, förhoppningsvis kan mhakman kommentera mitt resonemang.

Det jag menar med att filsystemet inte "ballar ur" när en radering hänger sig är att alla filer man ville behålla fortfarande är intakta och tills motsatsen bevisats så fungerar boxen lika bra (eller dåligt om man så vill) som tidigare. Inga obehagliga överraskningar som att nya inspelningar skriver över gamla till exempel.

<{POST_SNAPBACK}>

I praktiken är filerna inte intakta, eftersom man inte kan ta backup på dom och behålla dom intakta (inte med den "rätta" (officiella) metoden iallafall). Vid backup kan man därför råka ut för överraskningar som t.ex att en backup inte fungerar till mer än 50% därför att resten av filstorleken innehåller data från orelaterade och till och med raderade inspelningar. Huruvida detta beror på filsystemet är ju en annan sak.

Jag anser inte att det i nuläget finns belägg för att filerna påverkats av den misslyckade raderingen. Än så länge är det bara en teori vars samband med misslyckad backup inte är bevisad.

Skall vi ändå bygga upp en indiciekedja kring detta med raderingar som hängt sig så undrar jag, har du haft problem att ta backup på filer inspelade efter att boxen hängde sig?

Ok, skall vi komma längre än så då behövs det mera fakta. Ett beprövat sätt att skaffa fakta är att utföra lämpliga experiment och observera utfallet. Eftersom jag jobbar med liknande grejor (fast då har jag den hela interna informationen som motsvarar vad Didan har) så skulle jag kunna föreslå några sådana experiment.

Innan vi går in på det har jag dock ett spörsmål. Antag att vi kommer fram till att det med till visshet gränsande sannolikhet är filborttagning som ställer till oreda på disken på ett sådant sätt att boxen kan spela filer men att USB Downloader inte klarar att överföra de rätt. Med USB Downloader menar jag både den kod som körs på PC och den kod som körs i boxen när man laddar ner filer.

Vad tänker Ni göra med den informationen? Delge Didan naturligtvis. Men Didan har ju inget problem med att ta reda på detta utan vår hjälp. De vet exakt hur filsystemet skall vara när det är friskt och då är det bara att ta en dålig box, köra hexdump (om de inte har ett specialverktyg för ändamålet) och kolla vad som är fel. De har ju också koden till både firmware och USB Downloader.

Eftersom Didan har inte fixat det här problemet på över 1 år så måste jag utgå ifrån att de inte vill.

Alternativet vore ju att Didan har tappat bort USB Downloader koden (eller aldrig haft den) och även informationen om hur filsystemet är uppbyggt och alltså jobbar nu i blindo. Även om det inte är omöjligt så är det väl ändå inte sannolikt, eller vad tycker Ni?

/Mikael

Skall vi ändå bygga upp en indiciekedja kring detta med raderingar som hängt sig så undrar jag, har du haft problem att ta backup på filer inspelade efter att boxen hängde sig?

<{POST_SNAPBACK}>

Ja, så vitt jag kan se så fungerade överföringarna utan problem under någon månad efter köpet, fram tills dess att en radering hängde sig. I samma veva uppgraderade jag till firmware 1.18 så den kan ju också ha något med det att göra. Sedan dess har 90+ % av alla överföringar jag gjort innehållit data från andra filer (något jag upptäckt först på tid och bekräftat genom att granska loggarna bakåt i tiden), även från borttagna inspelningar (som jag inte fört över till datorn, så det är inget i datorns filsystem som påverkar detta), ibland så pass lite att överföringen ändå varit användbar men ofta ändå så pass mycket att backupen inte gått att titta på. Filstorlekarna matchar mellan box och dator, men en del av den storleken utgörs alltså i boxen av rätt data men i datorn av främmande data.

Sedan jag uppgraderade till 1.18 har jag inte haft några problem med "låsta" raderingar. Däremot har jag problem hela tiden med ihopblandade backupper.

Redigerat av DVBgeek, 07 december 2006 - 13:16.

Skall vi ändå bygga upp en indiciekedja kring detta med raderingar som hängt sig så undrar jag, har du haft problem att ta backup på filer inspelade efter att boxen hängde sig?

<{POST_SNAPBACK}>

Ja, så vitt jag kan se så fungerade överföringarna utan problem under någon månad efter köpet, fram tills dess att en radering hängde sig. I samma veva uppgraderade jag till firmware 1.18 så den kan ju också ha något med det att göra. Sedan dess har 90+ % av alla överföringar jag gjort innehållit data från andra filer (något jag upptäckt först på tid och bekräftat genom att granska loggarna bakåt i tiden), även från borttagna inspelningar (som jag inte fört över till datorn, så det är inget i datorns filsystem som påverkar detta), ibland så pass lite att överföringen ändå varit användbar men ofta ändå så pass mycket att backupen inte gått att titta på. Filstorlekarna matchar mellan box och dator, men en del av den storleken utgörs alltså i boxen av rätt data men i datorn av främmande data.

Att även inspelningar gjorda efter hängningen strular gör att det i mina ögon blir mindre sannolikt att den har med saken att göra, återigen med reservation för att jag inte vet hur filsystemet fungerar. Men om det på minsta sätt liknar de filsystem jag jobbat med så bör det inte kunna bli den typen av trassel med filer som är skrivna efter "skadan'.

Ärligt talat tror jag att man oftast går över ån efter vatten när man söker denna typ av intrikata samband (även om det kanske var jag som väckte tanken). I de flesta fall tycker jag det brukar vara banala buggar i mjukvaran, som att man får teckenfel eller overflow i någon variabel.

Att även inspelningar gjorda efter hängningen strular gör att det i mina ögon blir mindre sannolikt att den har med saken att göra, återigen med reservation för att jag inte vet hur filsystemet fungerar. Men om det på minsta sätt liknar de filsystem jag jobbat med så bör det inte kunna bli den typen av trassel med filer som är skrivna efter "skadan'.

Ärligt talat tror jag att man oftast går över ån efter vatten när man söker denna typ av intrikata samband (även om det kanske var jag som väckte tanken). I de flesta fall tycker jag det brukar vara banala buggar i mjukvaran, som att man får teckenfel eller overflow i någon variabel.

<{POST_SNAPBACK}>

Åtminstone funkade överföringarna i början, och om det var den misslyckade raderingen eller uppgraderingen till 1.18 (eller kombinationen av de båda sakerna) som orsakade att problemen med ihopblandade filer började är svårt att avgöra men något av det bör det ha varit.

Efter att ha nollställt hårddisken med dd, kollat ytan med HDTune och gjort en full formattering i boxen, så kan jag nu konstatera att problemet inte har försvunnit med ett färskt filsystem och bekräftat frisk hårddisk. Jag fortsätter att få "omöjliga" ihopblandningar av inspelningar gjorda från olika muxar och på olika tider/dagar. Som vanligt är det endast vid backup som felen uppstår, i boxen fungerar alla filer som dom ska.

Jag har observerat att sedan jag nollställde hårddisken har inga raderingar låst sig så det kan inte vara detta som orsakar felet. Inga andra filoperationer har heller krånglat så felet i filsystemet bara finns där oavsett avsaknaden av krascher, och borde därför finnas på alla boxar (eftersom min box efter nollställningen är i fabriksskick (med firmware 1.18) och filsystemet enbart påverkas av mjukvara så länge hårddisken är frisk (och det är den)).

Som vanligt gäller att om jag för över samma filer via GetHAV så får jag inga ihopblandningar.

Det verkar alltså som om det är själva filsystemshanteringen som behöver ses över grundligt eftersom filsystemet nu korrumperar sig självt även utan "yttre påverkan" som t.ex krashade filoperationer.

Så då borde vi väl kunna isolera felet till att det är ett "alltid existerande" problem (dvs det triggas inte av några hängda filoperationer eller andra krascher). Antingen ligger felet i firmware eller i USB Downloader. Användare av TEAC och Legend har rapporterat samma fel och den mest gemensamma nämnaren är ju USB Downloadern, så jag misstänker att om den fixas till att läsa filer på samma sätt som boxen gör internt, så löser sig problemet på alla kloner...

EDIT 2007-02-28 09:15
Glöm USB Downloader, filsystemet i sig är ostabilt. Nu har även boxen, för första gången sedan jag skaffade den, misslyckats med att adressera en fil korrekt, vilket resulterade i en "greenscreen". Ljudet försvann först, sedan bilden som bröts sönder i block och blev en helt grön yta varefter bilden blev svart och det dröjde några sekunder innan bild och ljud kom tillbaka. Under tiden bild och ljud var borta jobbade hårddisken hårt, lät ungefär som vid en scandisk eller defrag. Problemet upprepades även om man spolade tillbaka så det var inget tillfälligt utan felet ligger förmodligen i filsystemet. Dock lyckades boxen bra mycket bättre totalt sett med att läsa filen än vad USB Downloader klarade (förlorade bara några sekunder i boxen medan jag förlorade halva programmet i USB Downloader....).

Nu får minsann Dilog fixa detta...

Redigerat av DVBgeek, 28 februari 2007 - 08:16.

DVBgeek; Du uttrycker dig så som om det är USB Downloader programmet som läser disken och det tolkar jag som om det skulle vara det programmet som adresserar hårddisken. Vet du om det är så? Jag tycker det verkar mycket märkligt. Det är väl firmware'n i boxen som accessar disken. USB Downloader skickar väl bara (högnivå-) kommandon till boxen och vet inget om disken. Så borde det ju vara. Ville bara kolla om du vet hur det, på teknisk nivå, är implementerat eller om du bara uttrycker dig som en användare (och ser box och mjukvara som en svart klump).

Kan berätta att min syrra inte har kört 1.18 (som jag trodde), fick nyligen reda på varför. När hon har 1.18 i boxen så kan hon inte avkoda flera filer. Boxen avkodar/kopierar en fil men slutar innan den tagit bort original filen. Den tycker väl antagligen att det är något fel på disken. Går sedan inte vidare med några fler filer. Detta har gjort att hon bytte tillbaks till äldre firmware.

Med andra ord olika firmware hanterar disken olika. Vilket tyder på att dom gjord ändringar (troligen fixat buggar och förbättrat felhanteringen (min gissning)).

DVBgeek; Du uttrycker dig så som om det är USB Downloader programmet som läser disken och det tolkar jag som om det skulle vara det programmet som adresserar hårddisken. Vet du om det är så? Jag tycker det verkar mycket märkligt. Det är väl firmware'n i boxen som accessar disken. USB Downloader skickar väl bara (högnivå-) kommandon till boxen och vet inget om disken. Så borde det ju vara. Ville bara kolla om du vet hur det, på teknisk nivå, är implementerat eller om du bara uttrycker dig som en användare (och ser box och mjukvara som en svart klump).

Kan berätta att min syrra inte har kört 1.18 (som jag trodde), fick nyligen reda på varför. När hon har 1.18 i boxen så kan hon inte avkoda flera filer. Boxen avkodar/kopierar en fil men slutar innan den tagit bort original filen. Den tycker väl antagligen att det är något fel på disken. Går sedan inte vidare med några fler filer. Detta har gjort att hon bytte tillbaks till äldre firmware.

Med andra ord olika firmware hanterar disken olika. Vilket tyder på att dom gjord ändringar (troligen fixat buggar och förbättrat felhanteringen (min gissning)).

<{POST_SNAPBACK}>

Boxen adresserar filerna korrekt vid uppspelning/avkodning/inspelning (eller gjorde; nu har det börjat krångla efter senaste omformatteringen). Vid access med GetHAV adresseras filerna också korrekt. Boxen använder sig så vitt vi vet av två filtabeller och i den ena skrivs det tydligen fel eftersom GetHAV klagar på det men ändå kan läsa filerna tack vare den redundanta informationen som enligt vissa ligger inne i filernas "metadata" (Handan-specifika headers). Eftersom det bara är USB Downloader som inte kan läsa filerna korrekt och blandar ihop sektorer från hårddisken så antar jag att USB Downloader antingen
1) adresserar hårddisken själv och då inte är medveten om att det finns en redundant filtabell (teori: den får informationen eftersom den är en del av filerna, men den används inte)
eller 2) så använder boxen vid anrop från USB Downloader en annan filsystemsdrivare (än den som används vid interna funktioner som uppspelning t.ex) som inte är medveten om den redundanta filtabellen utan blint litar på den första filtabellen och bara skickar den redundanta informationen som en del av filen.
Vilken av ovanstående teorier som är mest med verkligheten överensstämmande vet jag inte, men jag tror att någon av dom bör vara ganska nära. Hur som helst blir resultatet att backup via USB Downloader inte fungerar, och eftersom backupfunktionen var det säljande argumentet i mitt fall, är jag mindre glad på Dilog just nu och bryr mig inte om vad det är som är fel bara dom fixar det på stört...

Vi vet en ändring som gjorts i filsystemet iallafall; i tidiga versioner stöddes endast 120 GB och det är väl möjligt att ändringen implementerades som en sekundär filtabell (lappa och laga-metoden) och därmed kanske den primära filtabellen fortfarande försöker adressera bara 120 GB och att det därför kan bli fel i den på något sätt (men det vet vi ju inte eftersom filsystemet är Handans egna påhitt och inte något av de väldokumenterade filsystem som VxWorks stödjer).

Jag ville minnas att boxen kunde koda av flera filer i en kö i 1.17, men det har inte funkat för mig heller i 1.18. I min box tar den däremot bort orginalfilen helt korrekt men som sagt, fortsätter inte med flera filer. Men eftersom timern inte funkar som den ska i 1.17 (men något bättre i 1.18) så nedgraderade jag inte.
Jag har rapporterat felet med att avkodningskön inte funkar längre.

Redigerat av DVBgeek, 28 februari 2007 - 16:30.

Det talas här om uppgradering till 1.18. På Dilogs websida finner jag ingen nerladdning av 1.18. Hur gör ni. Och vad är det som förbättras med 1.18. Jag tycks ha 1.01 (26/6 2007).

Det talas här om uppgradering till 1.18. På Dilogs websida finner jag ingen nerladdning av 1.18. Hur gör ni. Och vad är det som förbättras med 1.18. Jag tycks ha 1.01 (26/6 2007).

1.01 är nyare (konstigt, eller hur?) och stödjer Boxer Navigator. 1.18 är för den äldre modellen av DT-550 som inte stödde Navigator.

Sitter det något batteri i denna box? Har en box som tappar minnet och jag får göra kanalsökningen om och om igen...