Month: Mai 2010

Nachdem ich grade eine nette Story über zwei Deutsche, die mal eben nach USA jetteten, um iPads zu ernten, gelesen habe, kurz was zu meinem persönlichen »Vorbestellungs-Waterloo« ;)
Um noch in den Genuß des kostenlosen JTAG-Boards zu kommen, vorbestellte ich am 18. März bei NewIT meinen GuruPlug-Server (Plus), den nächste Evolutionsstufe des SheevaPlug.
Ich weiß nicht mehr, für wann die GuruPlugs initial angekündigt waren, ich meine aber »im April 2010«; im Forum von NewIT wurde am gleichen Tag ein erster voraussichtlicher Liefertermin zu NewIT kommuniziert:

Re: GuruPlug shipping estimates?
« Reply #8 on: 18 March 2010, 10:23:45 AM »
We have been given an estimated delivery date of the 20th April, if this is correct we will despatch all orders within 48 hours or receiving them.
When we get a more accurate date nearer the time we will update this post.

 
Tja, am 23. April hieß es dann:

Re: GuruPlug shipping estimates?
« Reply #14 on: 23 April 2010, 06:30:59 AM »
We received a delivery update from Globalscale last night, this tells us that our shipment will be leaving China next week; this is sent over to Hong Kong then onto the UK by air. With previous orders once we are informed that the shipment has left China it normally takes about 7 days to get to us. But as I am sure most of us are aware of the disruption the volcano has caused the airlines, there maybe a small delay whilst they are clearing the backlog of freight being sent by air.
Once we have confirmation of the flight leaving Hong Kong we can then announce a firm delivery date to ourselves and therefore a despatch date for all orders.
Many thanks for you patience.

 
Die »next week« kam, und ging, ohne GuruPlugs, aber neuen Aussagen:

Re: GuruPlug shipping estimates?
« Reply #30 on: 30 April 2010, 03:20:38 PM »
Globalscale have always had this on their products – 2-4 weeks from date of ordering, this is how they work, customer places order, globalscale manufacture unit then ship it.
We are currently waiting on the flight details from Hong Kong, if pushed for an estimate (because until i receive the flight number thats all i can give), then i would say they will land in the UK around Tuesday/Wednesday. Once this lands in the UK, we then have to process through HM Customs and Excise, and arrange delivery to ourselves, this normally take a day or two. So i would like to think that a fair estimate would be we will receive them on Friday next week, so looking at the quantity of pre orders we have i would say the majority would be despatched on the following Monday 10/5/10.
Once again, many thanks for you patience.

 
Allerdings, auch aus dem Versand am 10. Mai wird nichts werden, wie ein anderer Nutzer berichtet:

Re: GuruPlug shipping estimates?
« Reply #32 on: 04 May 2010, 04:32:57 PM »
Hi midtskogen,
I just got the same update from Jason about an hour ago, so safe to assume same applies:
Hello there
We received a delivery update from Globalscale on the 29/4/10, this tells us that our shipment will be leaving China next week; this is then sent over to Hong Kong then onto the UK by air. With previous orders once we are informed that the shipment has left China and it normally takes about 7 days to get to us. But as I am sure most of us are aware of the disruption the volcano has caused the airlines, there maybe a small delay whilst they are clearing the backlog of freight being sent by air.
Once we have confirmation of the flight leaving Hong Kong we can then announce a firm delivery date to ourselves and therefore a despatch date for all orders, we will aim to despatch all pre orders within 72 hours of receiving the units in to ourselves.
Please keep an eye on our Forum, which is where we will post more accurate delivery dates once we get them.
Best regards
Jason King

 
Bislang wurde jedenfalls nichts Neues seitens NewIT kommuniziert, auffällig sind aber die »will be leaving China next week«-Texte sowohl am 23.03. als auch am 04.05.; augenscheinlich wird der Termin wöchentlich um eine Woche nach hinter geschoben ;) Insofern bin ich dann sehr gespannt, was man im Spätsommer in Deutschland von der WePad-Auslieferung hören wird — wobei ich beide nicht vergleichen möchte, denn der GuruPlug ist nur eine moderate geänderte Hardware zu den schon bestehenden Sheeva- und eSATA-Sheeva-Plugs …

Vorab: Willkommen im Club — das yaVDR-Team bloggt nun auch ;)
Langsam nimmt mein VDR-Server-und-Client-Projekt Formen an. Ich hänge zwar noch immer an der Fernbedienungsfrage (lirc_ttusbir wie auch der Treiber für das normale serielle Homebrew-IR-Interface hängen sich auf der Zielhardware (ASUS V-M3N8200 Mainboard, AMD Athlon(tm) 7750 Dual-Core Processor) weg), aber das außen vor, funktionieren timergesteuert Aufnahmen, das Abspielen von Alt-VDR-Aufnahmen (der Wohnzimmer-VDR ist noch ein antikes 1.4.7-Schätzchen) via NFS-Mounts (aufgrund von Rechteproblemen, UID vdr-alt != vdr-neu, leider nur blankes Abspielen, kein »Waschen, Schneiden, Legen«), lokales Schneiden von Aufnahmen¹ … kurz eigentlich erst einmal alles, was VDR können sollte.
Heute habe ich dann mal angefangen, weitere, liebgewonnene Add-ons und Plugins zu suchen und zu installieren — und bin sehr angetan von vdr-plugin-fritzbox, vdr-plugin-timeline, vdr-plugin-remoteosd sowie vdr-plugin-remotetimers. Denn, anders als bei xineliboutput, wo nur ein einem Tag kompilierte Versionen zueinander kompatibel sind (jedenfalls kann ich mit aktuellen vdr-sxfe weder meinen 1.4.7er noch den 1.6.0er an einem entfernten Ort bedienen, selbst aus anderen Quellen stammende 1.7er vdr-Installationen sind eher problembeladen denn nicht :(), steuert remoteosd 0.1.0 von meinem yaVDR aus meinen 1.4.7er mit svdrpext 0.0.1 — so soll das sein!
Das ist insofern relevant, als daß ich im Endausbau einen bis mehrere VDR-Server für programmierte Aufnahmen haben möchte, die von einer zentralen Instanz – dem (ya)VDR im Wohnzimmer – programmiert werden können sollen. Super wäre ein Frontend, welches diese mehreren VDR logisch zusammenfaßt und die Aufnahmen entsprechend verteilt; aber im ersten Schritt reichte es, wenn ich, das ist noch der Knackpunkt, mehrere VDR von einem zentralen VDR fernkonfigurieren könnte. Denn, soweit ich bislang gesehen habe, gibt es keinen vorgesehenen Weg, eine 1:n-Beziehung zu unterstützen (1 Frontend-VDR und n Backends), über 1:1 kam man bislang leider nicht hinaus².
Ein anderes Thema, an dem ich derzeit hänge: die Einbindung der T-Entertain-IPTV-Kanäle (des öffentlich-rechtlichen Fernsehens, der Rest ist ja »grundverschlüsselt«). Mit der Kanalliste, die ich im Netz gefunden habe, blitzte anfänglich mal was auf, mittlerweile kommt aber »Kanal nicht verfügbar« und die Kanäle werden als verschlüsselt angezeigt :( Tipps werden gerne angenommen:

54:Das Erste IPTV;IPTV:1:IPTV|S1P1|UDP|239.35.129.11|10000:P:0:256=27:257=deu;258=AC3:259:4AE2:28106:0:0:0
5478:Eins HD;IPTV:10:IPTV|S1P1|UDP|239.35.10.1|10000:P:0:256=27:257=deu;258=AC3:259:4AE2:11100:0:0:0

Schlußendlich suche ich dann noch nach einer »vernünftigen« EPG-Variante für die Sender von BBC und ITV (Astra 28,2° Ost), sodaß automatische Aufnahmen »immer« funktionieren und nicht nur, wenn grade ein EPG-Update lief (BBC, ITV und andere senden nur die EPG-Info »jetzt« und »nächstes Programm«, anders als die meisten deutschsprachigen Sender zumindest auf Astra, die das Programm für 3 bis 5 Tage im voraus übermitteln). Auf dem alten VDR hatte ich da mal einen XML2irgendwas-Mechanismus funktional am Start, aber der tut leider auch nimmer …
So, dann werde ich mich mal schlauzumachen versuchen, wie man die yaVDR-Sourcen als Basis für eigene Erweiterungen nimmt, z. B. um nicht »mitgelieferte« Plugins zu kompilieren … Als Brute-Force-Ansatz könnte man ja remoteosd einfach als remoteosd1, remoteosd2, remoteosd3 durchkompilieren und einbinden, mit anderen Pfaden für die Konfiguration, versteht sich.
___