Palmclub Forum

notgo · #**221** 29 december 2005, 19:19

Citaat:

Oorspronkelijk geplaatst door Gazpacho

Kun je ook in de conduit veranderen dat ie de losse bestandjes kan pakken, en niet een zip bestand?

Ik heb er al over zitten denken om een generieke installer conduit te maken. Een conduit die zips en pdb's kan downloaden en die installeert tijdens het hotsyncen. Er zijn nog wel meer dingen die je automatisch zou willen doen. Dan kan hij meer dan alleen FBTV.

Een nadeel is wel dat het bandbreedte gaat kosten bij Frans en de andere aanbieders van pdb's. Ik weet niet of ik dat kan maken. Nu gaat het bij xs4all af en dat is geen probleem.

fransbr · #**222** 30 december 2005, 08:56

Citaat:

Oorspronkelijk geplaatst door notgo

Een nadeel is wel dat het bandbreedte gaat kosten bij Frans en de andere aanbieders van pdb's. Ik weet niet of ik dat kan maken. Nu gaat het bij xs4all af en dat is geen probleem.

Heb je een indicatie van hoevaak de zip per dag opgehaald wordt? De pdb's worden nu (rechtstreeks) tussen de 30 en 70 keer per dag (gemiddeld iets van 50 dus) opgehaald.

Mmmm · #**223** 01 januari 2006, 23:13

Hey Frans,
Volgens mij reageert FBTV wat vreemd op de jaarwisseling: bij opstarten blijft datum 31/12 in beeld, en de rode datumlijn ontbreekt (ook als je doorscrollt naar de juiste datum/tijd); menu-optie 'Navigate - Ga naar...' werkt ook niet ('Navigate - 12 uur >>' of '<<' overigens wel)
Sorry voor het slechte nieuws zo aan het begin van 2006, maar verder natuurlijk de allerbeste wensen!
gr Maarten

fransbr · #**224** 02 januari 2006, 07:07

Een samenloop van omstandigheden denk ik. De "bug" waar jij het over hebt is niet echt een bug: vorig jaar (klinkt zo'n eind weg

) gebruikte FBTV intern de datums 30-12-2005, 31-12-2005, 32-12-2005, 33-12-2005. Met het ophalen van de data op 1-1-2006 had alles weer vanaf het begin moeten beginnen ware het niet dat de parser het op 1 januari blijkbaar niet (goed) gedaan heeft waardoor de data van 31 december nog op de site stond. Dit is (gisteren) inmiddels opgelost. (Als je de data rechtstreeks opgehaald had, had het al goed moeten zijn).

notgo · #**225** 02 januari 2006, 07:35

Citaat:

Oorspronkelijk geplaatst door fransbr

Heb je een indicatie van hoevaak de zip per dag opgehaald wordt? De pdb's worden nu (rechtstreeks) tussen de 30 en 70 keer per dag (gemiddeld iets van 50 dus) opgehaald.

Nee, helaas. xs4all biedt geen statistieken over de homepage. Ik heb geen flauw idee hoeveel mensen de conduit gebruiken. Ik dacht dat het wel meeviel. Aan de reacties hier te zien, denk ik hooguit 10 man ofzo.

fransbr · #**226** 02 januari 2006, 08:28

Citaat:

Oorspronkelijk geplaatst door notgo

Aan de reacties hier te zien, denk ik hooguit 10 man ofzo.

Uitgaand van de reakties hier ging ik ook uit van een man of 30 maximaal. Daarvan zijn er dus volgens jou 10 de conduit gaan gebruiken, dus blijven er 20 over. Toch worden de bestanden nog tot 70 maal per dag rechtstreeks opgehaald. Reken dus maar op een veelvoud. 100 conduit-gebruikers zou mij niets verbazen.

notgo · #**227** 02 januari 2006, 08:42

Citaat:

Oorspronkelijk geplaatst door fransbr

Reken dus maar op een veelvoud. 100 conduit-gebruikers zou mij niets verbazen.

Als je uitgaat van 100 gebruikers die elke dag 500 Kb aan pdb's ophalen, kom je op 50 MB per dag. Gaat best hard. 1500 MB per maand. Zippen scheelt trouwens al de helft.

Nog maar even bij xs4all houden?

fransbr · #**228** 02 januari 2006, 09:27

Graag

notgo · #**229** 02 januari 2006, 09:32

Citaat:

Oorspronkelijk geplaatst door Gazpacho

Kun je ook in de conduit veranderen dat ie de losse bestandjes kan pakken, en niet een zip bestand?

Citaat:

Oorspronkelijk geplaatst door notgo

Nog maar even bij xs4all houden?

Citaat:

Oorspronkelijk geplaatst door fransbr

Graag

Daar heb je je antwoord

rudyheidenis · #**230** 02 januari 2006, 10:28

Citaat:

Oorspronkelijk geplaatst door notgo

Nee, helaas. xs4all biedt geen statistieken over de homepage. Ik heb geen flauw idee hoeveel mensen de conduit gebruiken. Ik dacht dat het wel meeviel. Aan de reacties hier te zien, denk ik hooguit 10 man ofzo.

Wist je al dat ik hem ook gebruik?

joop · #**231** 08 januari 2006, 19:30

Ik ben ook een "anonieme" gebruiker.
Omdat de description file niet meer klopte, was ik overgestapt naar de update mogelijkheid die FBTV zelf biedt. Ik gebruik hiervoor een bluetooth-verbinding. Na de installatie van de verbeterde .dll versie van NotGo, doet de Hotsync het weer goed. Gebruik het programma dagelijks!

Joop

Gazpacho · #**232** 09 januari 2006, 23:17

En toch werkt er nog iets niet goed in notgo's conduit

Ik schreef dat ik eerst last had van het feit dat dezelfde update meerdere keren per dag opgehaald werd, wat de Hotsync danig vertraagt bij gemis aan een cancel knop. Dat was weer een tijdje verdwenen, maar het is weer opgedoken, kijk:

Citaat:

HotSync operation started for Treo650 on 01/10/06 00:11:31
Start FBTV installatie
Ophalen zip bestand van internet
Uitpakken bestand C:\Program Files\Sony Handheld\fbtv.zip
installeren FBTV_Prog.pdb op palm
FBTV: Installing 1842 records to table FBTV_P
FBTV: End of sync
installeren FBTV_Desc.pdb op palm
FBTV: Installing 1842 records to table FBTV_Desc
FBTV: End of sync
Bestanden correct op de palm gezet

HotSync operation started for Treo650 on 01/10/06 00:09:16
Start FBTV installatie
Ophalen zip bestand van internet
Uitpakken bestand C:\Program Files\Sony Handheld\fbtv.zip
installeren FBTV_Prog.pdb op palm
FBTV: Installing 1842 records to table FBTV_P
FBTV: End of sync
installeren FBTV_Desc.pdb op palm
FBTV: Installing 1842 records to table FBTV_Desc
FBTV: End of sync
Bestanden correct op de palm gezet

HotSync operation started for Treo650 on 01/10/06 00:04:36
Start FBTV installatie
Ophalen zip bestand van internet
Uitpakken bestand C:\Program Files\Sony Handheld\fbtv.zip
installeren FBTV_Prog.pdb op palm
FBTV: Installing 1842 records to table FBTV_P
FBTV: End of sync
installeren FBTV_Desc.pdb op palm
FBTV: Installing 1842 records to table FBTV_Desc
FBTV: End of sync
Bestanden correct op de palm gezet

Iemand hier meer nog last van?

rudyheidenis · #**233** 10 januari 2006, 06:56

Ja, ik.

fransbr · #**234** 10 januari 2006, 07:05

Misschien dat de PC tijd afwijkt (nog zomertijd ofzo)?

In principe is het zo dat een conduit geen interactie met een gebruiker mag hebben (daarom baal ik ook nogal van Intellisync die constant vraagt of iets overschreven mag worden) en ik vrees dat een cancel button meer kwaad dan goed doet.

Frank · #**235** 10 januari 2006, 07:15

Citaat:

Oorspronkelijk geplaatst door Gazpacho

Iemand hier meer nog last van?

Ik ook, maar ik ben al lang blij dat ik op deze manier gegevens in mijn tv-gids krijg

(Als ik via het programma FBTV probeer te updaten, krijg ik een "Error 40: Database not opened")

notgo · #**236** 10 januari 2006, 13:18

Citaat:

Oorspronkelijk geplaatst door Gazpacho

En toch werkt er nog iets niet goed in notgo's conduit

Ik schreef dat ik eerst last had van het feit dat dezelfde update meerdere keren per dag opgehaald werd, wat de Hotsync danig vertraagt bij gemis aan een cancel knop. Dat was weer een tijdje verdwenen, maar het is weer opgedoken, kijk:

Kun je zien waar de FBTV_Prog.pdb neergezet wordt en welke datum/tijd hij heeft?

Doe je de hotsync soms 's ochtends vroeg? Frans zet de nieuwe pdb's er pas om 8:45 op. Ik zet ze om 9:00 uur klaar. Als je voor die tijd hotsynct, haalt hij de files van de dag ervoor van het internet. De volgende keer controleert hij of de pdb van vandaag is maar die staat nog op gisteren. Dus haalt hij weer een nieuwe op van internet etc.. etc..

Oplossingsrichtingen:
- Niet syncen tussen 0:00 uur en 9:00 uur

- Frans en ik zetten de bestanden eerder klaar.
- Controleren of de opgehaalde pdb anders is dan die het laatst gesynct is. Zo niet (in dit geval zal hij dus hetzelfde zijn), niets installeren. Je houdt dan nog het ophalen maar niet meer het trage installeren.
- Anders..

ghia · #**237** 10 januari 2006, 13:54

Citaat:

Oorspronkelijk geplaatst door notgo

Oplossingsrichtingen:
- Niet syncen tussen 0:00 uur en 9:00 uur

- Frans en ik zetten de bestanden eerder klaar.
- Controleren of de opgehaalde pdb anders is dan die het laatst gesynct is. Zo niet (in dit geval zal hij dus hetzelfde zijn), niets installeren. Je houdt dan nog het ophalen maar niet meer het trage installeren.
- Anders..

- Anders kan je ook in je HTTP aanvraag voor de zip te downloaden het header field if-modified-since invullen met het tijdstip van je laatste download.
In het geval dat de zip vernieuwd is krijg je hem gewoon zoals altijd met status 200.
In het geval dat de zip hetzelfde is gebleven, gaat ie niet downloaden, maar krijg je statuskode 304. Daarmee weet je dan, dat je gelijk klaar bent met FBTV te syncen.

notgo · #**238** 10 januari 2006, 14:16

Citaat:

Oorspronkelijk geplaatst door ghia

Anders kan je ook in je HTTP aanvraag voor de zip te downloaden het header field if-modified-since invullen met het tijdstip van je laatste download.

Dat is inderdaad ook een goed idee. Het is wel afhankelijk of de server (in dit geval xs4all) dat ondersteund. Het is in ieder geval de moeite van het proberen waard.

ghia · #**239** 10 januari 2006, 14:23

Andere manier is om voor de GET een HEAD aanvraag te doen, deze geeft je de bestandsgegevens in de response header en daar zit ook de datum van de ZIP bij.

Gazpacho · #**240** 10 januari 2006, 14:43

Citaat:

Oplossingsrichtingen:
- Niet syncen tussen 0:00 uur en 9:00 uur

Dat is het probleem dan geweest. Ik heb net even getest en nu doet hij het inderdaad fijn. Ik sync inderdaad nogal vaak na middernacht.

Mocht dit eenvoudig op de lossen zijn met de technische dingen die ghia suggereerde, en je er tijd voor hebt: graag.

En anders kan ik er zo ook wel mee leven.

Nog een vraagje: ik heb het idee dat de .pdb bestanden, die toch vrij groot zijn, sneller handmatig met de hotsync op de Palm komen (via Quick Install) dan dat ze via de conduit opgezet worden. Kan dit kloppen?

Er zijn 2 actieve gebruikers die momenteel deze discussie bekijken (0 leden en 2 gasten)

Palmclub Forum

[Palm TV Gids] FBTV 2.0 / 2.2.0