Look in: hxxp://user.xmission.com/~gazelle/OSD_Firmware/

"The connection to the server was reset while the page was loading."

Doesn't the OSDng firmware attempt to download something during install? I presume this will now fail, as surely would the package manager.

Hmm...


[edit: changed "http" in quote to "hxxp" as orange-on-light-grey is near impossible to read!]

NZavaloff - thanks to Google's increasing lameness with searching, I found it easier to get stuck in and examine the data than attempt to look for a solution by others. I then made my posting because you will note that it is a description, not code. Back when I was looking to how YouTube linking worked originally, I found a lot of examples, like Perl code or stuff with a lot of baggage for special options and/or OS peculiarities. Thus, again, I decided a worked guide that you can do with nothing more than Notepad and a browser would be best. Code is largely irrelevant without understanding.

So... you've written code to do this? For the OSD? Where? God knows the built-in YouTube client is prehistoric...


Best wishes,

Rick.

Finally, let me note (actually, confirm) that setting the time via the GUI does set both clocks (even if all you do is go to the screen [Tools -> Settings -> Date & Time] and hit enter twice).

I know the UI method sets both clocks. What I was looking for is a command-line way to do it programmatically so something else could keep the clock in step.

As for Busybox hacking, why not make setting both clocks the default option? I can't think why you'd want to set one and not t'other.


Best wishes,

Rick.

[itag%253D5]

I was going to post that I've not had time to look at this... but I've cracked it. Wasn't that hard, just damned fiddly.

Okay.

The video is me walking my cat along the driveway (figured you guys were sick of J-Pop!).

This is just rough'n'ready, okay?

Step one - get the video info file.

http://www.youtube.com/get_video_info?&video_id=ba7uZ1koImU&el=embedded&ps=default

This isn't hard, just pop the YouTube video ID into the &video_id parameter.


It will reply a scary shedload of stuff.

Notice it says "url_encoded_fmt_stream_map" at the top. This means stuff is encoded several times over and will need cut'n'paste fixing.

First, search for "itag%253D5". The file appears to provide separate URLs and access keys for different qualities, perhaps in an attempt to handle load balancing? The type 5 (naffest quality around) is all that the OSD can cope with, so that's what we'll stick to.

Once you have found it, backtrack until you can see "url%3Dhttp". Keep the http part, everything before and including can be discarded.

Now look for "%26fallback_host". That, and everything following, can be discarded.

You should be left with a file that looks like this:
   http%253A%252F%252Fo-o.preferred.orange-par1.v2.lscache1.c.youtube.co
   m%252Fvideoplayback%253Fupn%253DnRoni3Eqzu4%2526sparams%253Dalgorithm
   %25252Cburst%25252Ccp%25252Cfactor%25252Cid%25252Cip%25252Cipbits%252
   52Citag%25252Csource%25252Cupn%25252Cexpire%2526fexp%253D909903%25252
   C901604%2526algorithm%253Dthrottle-factor%2526itag%253D5%2526ip%253D9
   0.0.0.0%2526burst%253D40%2526sver%253D3%2526signature%253D13C8AE4B622
   8BD8B7E4BD68EBD71DCEC7B5951D0.C326D73C133C465B4FF4915061D6B9C667F299A
   8%2526source%253Dyoutube%2526expire%253D1335995606%2526key%253Dyt1%25
   26ipbits%253D8%2526factor%253D1.25%2526cp%253DU0hSSllUU19FUENOMl9RTld
   HOjVTUG1BQ0NRaVll%2526id%253D6daeee6759282265%26quality%3Dsmall

[don't use these links, the key value depends upon your IP address, you'll need to do this stuff yourself]


Now we've got ourselves a URL, it is time to perform some conversions to get it to work.
Search and replace as follows:

Search for	Replace with
%253F	?
%253D	=
%2526	&
%25252C	,
%26	&
%3D	=
%253A	:
%252F	/
%2526	&
&2C	,

[/size]

Yes, %2526 (&) is listed twice. This is intentional.


This will leave you with something that looks like a URL, in the following format:
   http://o-o.preferred.orange-par1.v2.lscache1.c.youtube.com/videoplayb
   ack?upn=nRoni3Eqzu4&sparams=algorithm,burst,cp,factor,id,ip,ipbits,it
   ag,source,upn,expire&fexp=909903,901604&algorithm=throttle-factor&ita
   g=5&ip=90.0.0.0&burst=40&sver=3&signature=13C8AE4B6228BD8B7E4BD68EBD7
   1DCEC7B5951D0.C326D73C133C465B4FF4915061D6B9C667F299A8&source=youtube
   &expire=1335995606&key=yt1&ipbits=8&factor=1.25&cp=U0hSSllUU19FUENOMl
   9RTldHOjVTUG1BQ0NRaVll&id=6daeee6759282265&quality=small


Toss this to your browser (or fetch into the OSD) and you'll see Tiny Alice running up the driveway with me. That old fashioned token stuff is no longer required. Probably half of the above isn't required either, but go with it...



There you go. How to turn a YouTube URL into a playable video.


Best wishes,

Rick.

See if you can compile this. It ought to do the job. [fingers crossed!]

/* hwclock [Rick's mix]

   Updates the RTC from the system clock.
     
   Version 0.01 2012/05/02

   NOT TESTED - just a hack-together from my poketime code. ;-)


   For the Neuros OSD.


   Copyright (c) 2012 Rick Murray.
   Released under the EUPL v1.1 (only).
   http://ec.europa.eu/idabc/eupl5

*/

#include <unistd.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <sys/time.h>
#include <sys/ioctl.h>

#include <linux/neuros_rtc.h>
#include "../../Neuros-Cooler/cooler/core/include/rtc.h"


int main(void)
{
   int       fp = -1;
   time_t    timeptr;
   struct tm *tp;
   struct rtc_time_type rtc_time;
   struct rtc_date_type rtc_date;   

   // read OS time
   time(&timeptr);
   tp = localtime(&timeptr);

   // copy to RTC time block
   rtc_date.year  = tp->tm_year;
   rtc_date.month = (tp->tm_mon + 1);
   rtc_date.day   = tp->tm_mday;
   rtc_time.hour  = tp->tm_hour;
   rtc_time.min   = tp->tm_min;
   rtc_time.sec   = tp->tm_sec;

   // open RTC
   fp = open("/dev/neuros_rtc", O_RDWR);
   if (fp < 0)
   {
      fprintf(stderr, "Unable to open RTC device.\n");
      exit(1);
   }

   // update RTC (date, then time)
   if ( ioctl(fp, RRB_SET_DATE, &rtc_date) != 0)
   {
      fprintf(stderr, "Unable to set system date.\n");
      close(fp);
      exit(2);
   }
   if ( ioctl(fp, RRB_SET_TIME, &rtc_time) != 0)
   {
      fprintf(stderr, "Unable to set system time.\n");
      close(fp);
      exit(3);
   }

   // done
   close(fp);   
   exit(0);
}

Here you go!

https://svn2.neurostechnology.com/neuros-bsp/trunk/toolchain/arm-linux/include/linux/neuros_rtc.h

[DATE]

Interesting.  A couple of questions:

1) Can you give us the compile command?  I.e., are there any defines or libs that need to be linked in?

Libs, no. Defines, yes, the rtc.h for the time structs. You can get a copy from https://svn2.neurostechnology.com/Neuros-Cooler/branches/clin-Neuros-Cooler/include/rtc.h

What I do (using pubuntu) is use gedit to write the code. Then in a console, I:
   cd ~/osd/neuros-bsp
   ./setup-rootfs
   source neuros-env
   cd ~/osd/our-apps/poketime
   arm-linux-gcc -o poketime poketime.c
   arm-linux-strip poketime
   cp /media/cofs3/poketime poketime
   cp /media/cofs3/poketime poketime.c

I type all that. I probably oughta make a shell script to do it for me.

2) A quick look at the source reveals that you include sys/ioctl.h twice, and then both times you call ioctl(), you call it twice (for no reason that I can see).  A case of double vision?

First time:
   #include <sys/ioctl.h>
   #include <sys/time.h>
   #include <sys/ioctl.h>
Yeah, I'm a wally...

Second time:
      if ( ioctl(fp, RRB_GET_DATE, &rtc_date) != 0)
  [...blah blah...]
      if ( ioctl(fp, RRB_GET_TIME, &rtc_time) != 0)

I've highlighted the differences.

Also, it would probably be better to have an option to take the current system time and poke that into the RTC, rather than needing it to be passed on the command line.  That's the most common situation and is what the real "hwclock" program does.

T'was looking for a way to get the time to be easily updateable. The "hwclock" ought to be fairly easy to get running, although I think it uses the Neuros Cooler libraries (do you have those?).

Actually, if you can compile my code, you can roll your own without libraries. Just take the part that reads the system time and the part that writes the RTC, and chuck away the rest. I can't do it myself right now as I've got a different SD card in to toss away adverts in recorded video to free up some space.


Best wishes,

Rick.

[moved from "Solved! etcetcetc (I don't remember this part )" topic]

Hehe, I should have known changing the subject line and unstickying the topic was too logical to work. So, had to split the topic and then resticky the original one [I'll let somebody else sticky this if they deem it worthy].
Phew.
I'm a little uncertain what is the point of changing the subject if all it does is alter a little bit of text nobody reads? Hmm...

Whatever, I have the next Nazo no Kanojo X to catch up on. Weirdest damn concept I've seen in a long time!


Best wishes,

Rick.

[poketime]

Hi,

[moved from "Solved! etcetcetc (I don't remember this part )" topic]

I didn't try the settime linked as it said it was for Torfu and I guessed the move to Qt4 would have changed some stuff.

In the end, I wrote my own.


The program (linked below) is called poketime. When called with no parameters, it will report the hardware clock and the system clock, like this:
   ~ $ poketime
   Current RTC date and time: 2012/04/30 00:26:27
   Current Sys date and time: 2012/04/30 00:26:27

Don't worry if the two are a second out, this could be the hemi-demi-semi-microsecond between prodding the RTC and then the soft clock. If they are a lot out, well, that's not so cool.


Otherwise, poketime takes exactly six parameters, as explained:
   ~ $ poketime ?
   Syntax: poketime <year (4 digits)> <month> <day> <hour (24h)> <minute> <second>

Thus...
   ~ $ poketime 1973 12 16 22 04 00
   ~ $ poketime
   Current RTC date and time: 1973/12/16 22:04:07
   Current Sys date and time: 1973/12/16 22:04:07
   ~ $ poketime 1973 12 16 22 08 00
   ~ $ poketime
   Current RTC date and time: 1973/12/16 22:08:05
   Current Sys date and time: 1973/12/16 22:08:04
   ~ $ poketime 2012 04 30 00 26 22
   ~ $ poketime
   Current RTC date and time: 2012/04/30 00:26:27
   Current Sys date and time: 2012/04/30 00:26:27

The time set is reflected in the UI in a few seconds.

Also attached is the source. As usual, released under EUPL.


Doesn't quite help with setting the time from my PC, but now I know I have something that will set the time correctly in both senses (I don't want to rely upon pulling the time from elsewhere, I just want to check in from time to time to keep the OSD accurate). That'll come later...


Best wishes,

Rick.

PS: In the examples, the first two dates and times given are my times of birth - I tend to use the latter frequently as a "test date", and the third is "now".

$ bin/busybox hwclock
hwclock: can't open '/dev/misc/rtc': No such file or directory

$ bin/busybox hwclock -r -f /dev/neuros_rtc
hwclock: RTC_RD_TIME: Invalid argument

RTC "cooler" code here to show you how it is done by Neuros.


Best wishes,

Rick.

[edited to remember closing quote tag ]

[there]

I don't know why you'd want to fiddle around with VB

Because I can knock off a custom task fairly quickly.

Since most of hte processing is done on the host side, you're just setting the OSD to whatever your local system says is the current time.

No - my OSD and satellite receiver run to British time. Everything else is on local (French) time. So to set one from the other, corrections would be necessary, however it is done.

Now, there is an interesting question!  I'm guessing it is the soft copy only, which is a shame, but the funny thing is, I can't figure out a way to test it.

The way I tested my battery was to set the clock, unplug the thing for five minutes, and see what the time was when reconnected.

Unfortunately, I could not get it to work:

Not a surprise. It is a rather non-standard way of implementing a clock, using the MSP430 microcontroller instead of a dedicated RTC. This saves a chip because the MSP430 also deals in some way or other with the remote control. Unfortunately, the damn thing is in the realm of closed source binaries so it's anybody's guess as to how to actually talk to the clock.
There's a build of Debian that will run on the OSD, found it years ago. It works, but time is "frozen" because there's no driver that understands that sort of clock.

To Chad, et al: I doubt there is much hope of getting this to work, is there?  Is there some other OSD-specific tool for accessing/changing the RTC?

Try rebuilding this for the Arizona/OSDng firmware? [I don't have my dev enviro available right now]

The UI has always lagged in terms of updating the time.  I wouldn't read too much into this.

Okay, thanks for the confirmation.


Best wishes,

Rick.

Hi,

Just changing the battery in my OSD (re. other threads...) and I noticed two whacking great capacitors stuck into my OSD and glue-gunned into place. In a comparison between this and the "dead" OSD, the dead one doesn't have these. My OSD is a "B9" and the dead one would, I guess, be slightly later as a "C9". Both are NOR flash versions with CF.

Does anybody with deep technical knowledge of the OSD hang around here? I'm wondering what these capacitors are actually for.


Here is the first mod, just beside the RAM. I note also that my (generally reliable!) OSD uses Hynix SRAM type 561620 [256M (16M x 16bit)], while the dead OSD uses Samsung SRAM 561632 [256M (4 x 4M x 16bit)]. Does the change in memory type/architecture have an effect on how the system behaves?

Here is the second mod, up by the SD slot but on the topside. The (single) FlashROM is the same.

With respect to the "dead" OSD, I plan to solder wires to connect the JTAG to a standard size IDC socket to permit the wiggler thingy to be attached. Fingers crossed that it's a bad flash update (recoverable) and not something having lost its magic smoke (not recoverable). It's going to be a hell of a job soldering up something that tiny!


Best wishes,

Rick.

Hi,

My OSD is networked, but not to the outside world. However I noticed a post from you using something called "expect" to do the time update manually from a host computer (my machine is kept correct, so that'll be okay). I may (in time) write a little VB applet to telnet into the OSD and fiddle the time, with a bit more checking (ie it'll look to see if we're recording first). It's probably also not a help that my OSD is in a different timezone. I'll snarf the expect stuff and play around with it.

Does that, by the way, update the hardware clock, or just the soft copy?


I left the OSD unplugged for five minutes after setting the time since changing the battery and I've come across an interesting quirk. I was about to panic due to the OSD losing 10 seconds in five minutes, however the onboard clock is actually still on time. It's the UI clock down the bottom right that doesn't seem to update until ten seconds have elapsed. I wonder if this is specific to the UI or if the recording is also laggy? [firmware: OSDng]


Best wishes,

Rick.

like the hack that I use for setting the time on the OSD,

Hi,

Sorry for resurrecting a long-ago thread, but I'd be interested in knowing how you keep your OSD's time in sync.


Best wishes,

Rick.

Thanks. I'll change it tomorrow (err... today).

Some might also say, you know, that lost time is a symptom of getting old. Something I'm finding I can comprehend more and more.


Best wishes,

Rick.