OSX recording frontend

[bagster]

I will make a OSX frontend for my OSD.  I'll do it for my personnal use, but if people like it I can share it.  That's why i'll ask for your help.
I've started it yesterday, I'll post the user interface soon.  I just want to know what you think of the 2 way I think of it.
1- My client will connect in telnet to my OSD, get the .recordings, allow to modify it and send it back to the OSD (and optionnaly, reboot it)
2- My client will only modify a .recordings that is on my shared drive.  In my init script of my OSD, i'll add a symlink of the /mnt/OSD/.recording to the one on my drive.  If I can't make the link before the file is read, i'll make it in a way that it will check if the network .rec and the local .rec match, and if they don't, it will copy them and reboot the OSD
3- My client will support both methods.

What do you think of it?

[bagster]

Interface will have these functions:

[JoeBorn]

Cool!  I didn't even know we had the .recordings interface you mentioned, I'm delighted to hear we do.  I'm going to cross post on the google groups mailing list, since that's where most of the developers are.

[tn]

I also had written 'EPG -> .recording' software for windows with Delphi.
(.recording file can be modified using TIniFiles very simply).

However, one have to reboot OSD after '.recording' is changed.
And  if OSD is recording that time,  the recording file will be lost, or even
the file system will be broken.

So right now, I do not think it is a good way to edit ".recording" file directly. (geeks only )

[illin_technology]

Wow, this interface would be great.  I'd be very excited to have this on my iMac.

[yanvrno]

If it could check recording status to see if a reboot was possible, it would be perfect addition to the OSD.
Very impressive, good work!
I love my my Macs

This is the kind of interfaces that would be great for controlling the record start and stop with a couple of buttons.

[greyback]

I'd love to see this too!

I'm wondering why a reboot is necessary. I'll have a look at the source and see.
-G

[greyback]

In case anyone is interested (or more clever than me & can actually figure out how the hell the Scheduler is working), it looks like the Scheduler's main methods are defined here:
http://svn.neurostechnology.com/filedetails.php?repname=linux-r3-main-app&path=%2Ftrunk%2Fdesktop%2Fsrc%2Fui%2Fnw-main.c&rev=0&sc=0

 
-G

[tn]

Maybe we have to restart "OSDmain" in order to change the schedule.
    static void SetScheduleTimer(int sc) <--Once osdmain read ".recordings", it set the timer inside, and do not read the file again.

Restarting  "osdmain"  is not so easy..
---------(I have not tested this script, maybe dangerous)----
#!/bin/sh
# restart osdmain
# recording? (/usr/local/bin/recording)
ps | grep recoding
if [ $? = 0 ]; then
# shutdown osdmain
/etc/init.d/nanoxd stop
rm /var/tmp/shm-neux-wm
# restart osdmain
/etc/init.d/nanoxd start
/etc/init.d/desktop start
fi
------------
So instead of restarting "osdmain",
I think using "reboot" is more simple and reliable.

ps | grep recoding
if [ $? = 0 ]; then
/sbin/reboot

(or if you are know that OSD is not recording,   "sync;reboot" is enough. )

[greyback]

Well the cleanest way would be to figure out how to make "osdmain" re-read the .recordings file. A simple program should do it, just calls the right function. Restarting osdmain just isn't nice.

Is that really that SetScheduleTimer(int sc) does? Man those comments need work.
-G

[nerochiaro]

Well the cleanest way would be to figure out how to make "osdmain" re-read the .recordings file. A simple program should do it, just calls the right function. Restarting osdmain just isn't nice.

Ok, first off to everyone in this topic, please if you want to further discuss this, join the developers mailing list: http://groups.google.com/group/Neuros-DM320Hardware
You will get a more prompt response by posting there, since most of the devs hang out there. Keeping eyes on forums is just too cumbersome, sorry.

Now, to the actual issue:

- why do you all mention "osdmain" ? I suppose you mean "desktop", which is the name of the component of the split osdmain that handles schedules (among other things). If you still have "osdmain" in your firmwares, it's time to upgrade, you will find a ton of changed things from the versions that still have monolithic osdmain. It's not really worth your time working on pretty old versions.

- to pull off the PC-side scheduler application as you suggest, you need to patch "desktop" to do any of the following:
A) add a periodic timer that checks if the date of modification of the schedules file is changed, and if so asks it to be reloaded (more on this below).
B) make desktop listen on the network for a simple message on certain port, and have your OSX app (or any other PC-side scheduler) send this message when it has changed the schedules file. when the desktop receive this message from network, it asks the file to be reloaded. Or write a tiny daemon that does this and then communicated with desktop via Neux WM messages.

- to force re-read of the schedules, you need to load the settings plugin for recorder (desktop already does this, and i see you already found this out from your previous posts). Then use NeuxPluginControl to send to the plugin the command INIT_SCHEDULE_DATA. This in theory reloads all the schedules. Then you call GET_NEXT_SCHEDULE_ALARM and use the returned value to set the next-scheduled timer (desktop already does this, so check how it does it).

A word of warning: I have not actually tried to do any of this, i just looked into the code. If none of you feels confident enough to try your hand at writing a patch on this and submit it, we can add this task to official developers schedule and do it internally for you.

Please quote any of the above on the mailing list for further discussion.
Thank you,
--
nero