Okay I managed to do some work on EmpWake tonight. Go get it at my empeg page.

New are lots of printf's to hopefully figure out what's causing it to not work for some people. Also some UI fixes, the ability to play the current FID instead of having to pick one in your config.ini, and automatic restart and reset of the alarm thread if you change the alarm time.

If you can't get it to bind to your Empeg menu, please send me whatever serial output you get when it's starting. If it does work for you, let me know how you like it, and what features you'd like to see.

BTW, I reserve the right to start going to three, four, and five decimal places in my version numbers if this thing is still a piece of poop.

It says:

Empwake v0.98 running as pid 60

Opening display...

and then silently exits with status 0. (OK, it just occured to me that this exit status tells us nothing, since you probably fork another instance of the program that does the actual job (in order to detach from terminal), and this code is from parent that exits after the fork anyway...) Anyway, the new process does exit immediately, too, as

./empwake; ps -ef

does not show it.

Edit: this happens whether the player runs or not (I tried this over serial console, via telnet with player running and 'regularly', through preinit.d).

Thanks for your effort!

Hm ok.. Well the next thing I do after opening the display is read the config.ini... But I have *all sorts* of debug prints in there.

I just added some more trace messages to help me figure exactly where it's dying... Can you give the new version a try?

This time I get this far:

EmpWake v0.98 running as pid 134

opening display...

loading config file...

opening config file...

fd: 4

bytes read: 953

Still no trace of it using ps -ef. I thought that perhaps it does not have enough free memory, so I tried enabling swapping. No change. Anything else I could try?

Well, here's where we're getting...

int loadConfig () {

  int fdConfigIni;

  int iBytesRead = -1;

  char szConfigIni[ 8193 ];	

  char *pszSection;

  char *pszTemp;

  char *pszEnd;

  char szActive[8];

  int errorflag = 0;

  int iLen;



	fprintf(stderr, "opening config file...\n");

	fdConfigIni = open( "/empeg/var/config.ini", O_RDONLY );

	fprintf(stderr, "fd: %d\n", fdConfigIni);		

	if (fdConfigIni != -1) {

		iBytesRead =  read( fdConfigIni, szConfigIni, 8193 );

		fprintf(stderr, "bytes read: %d\n", iBytesRead);

		szConfigIni[iBytesRead] = '\0';

		close (fdConfigIni);

		pszSection = strstr(szConfigIni, "[empwake]");

		if ( pszSection != NULL) {

			pszTemp = strstr(pszSection, "\n[");

			*pszTemp = '\0';



			pszTemp = strstr(pszSection, "\nfid=");

			if ( pszTemp != NULL) {

				pszTemp +=5;

				pszEnd = strchr(pszTemp, '\n');

				iLen = pszEnd - pszTemp;

				strncpy(szFid, pszTemp, iLen);

				printf("fid: %s\n", szFid);

			} else {

				printf("EmpWake warning: fid not specified in config.ini.  Using the currently selected playlist for alarm.\n");

				strncpy(szFid, "\01", sizeof(szFid) );

			}

			pszTemp = strstr(pszSection, "\nactive=");

			if ( pszTemp != NULL) {

				pszTemp +=8;

				pszEnd = strchr(pszTemp, '\n');

				iLen = pszEnd - pszTemp;

				strncpy(szActive, pszTemp, iLen);

				if ( strcasecmp(szActive, "true") == 0 ) {

					g_iAlarmEnabled = 1;

				} else {

					g_iAlarmEnabled = 0;

				}

			} else {

				printf("empwake: parse error line %d\n", __LINE__);			

				g_iAlarmEnabled = 0;

			}

			pszTemp = strstr(pszSection, "\ntime=");

			if ( pszTemp != NULL) {

				pszTemp +=6;

				pszEnd = strchr(pszTemp, '\n');

				iLen = pszEnd - pszTemp;

				strncpy(szAlarmTime, pszTemp, iLen);

				printf("time: %s\n", szAlarmTime);

				pszTemp = szAlarmTime;

				pszEnd = strchr(szAlarmTime, ':');

				if ( pszEnd != NULL) {

					*pszEnd = '\0';

					stcAlarmTime.tm_hour = atoi(pszTemp);

				} else {

					printf("empwake: parse error line %d\n", __LINE__);

				}

				pszTemp = pszEnd + 1;

				pszEnd = strchr(pszTemp, ':');

				if ( pszEnd != NULL) {

					*pszEnd = '\0';

					stcAlarmTime.tm_min = atoi(pszTemp);

				} else {

					printf("empwake: parse error line %d\n", __LINE__);

				}

				pszTemp = pszEnd + 1;

				stcAlarmTime.tm_sec = atoi(pszTemp);

			} else {

				printf("empwake: parse error line %d\n", __LINE__);			

				stcAlarmTime.tm_sec = stcAlarmTime.tm_min = stcAlarmTime.tm_hour = 0;

			}

		}

		else {

			printf("empwake: parse error line %d\n", __LINE__);

		}



	} else {

		printf("empwake: could not read config.ini: errno %d\n", errno);

	}

	fprintf(stderr, "-loadConfig()\n");	

	return 0;

}

.

I pretty much have debug statements *everywhere* that should be showing up somewhere. I looked for fall-through cases but I'm really confused as to why there's no other output happening somewhere. If it fails to parse the config.ini, it should be complaining somewhere...

I think the 8193 should be 8192 here:

iBytesRead = read( fdConfigIni, szConfigIni, 8193 );

And I see some places you use fprintf with stderr and other places you use printf. Maybe the printf is not going to the same output as stderr.

Presslab

Ah! Found it!!! (I think...)

I bet for those who are having this problem (Dragi and Bruno, among others) your [empwake] section is the *last* section in your config.ini. The code above looks for the next section with this:

pszTemp = strstr(pszSection, "\n.[");

*pszTemp = '\0';

.
So if it doesn't find that string, which should only happen if the empwake section is the last section of you config.ini, it's going to seg fault. Just duplicated it on mine.

Workaround for you guys *should* be to move the [empwake] section so it's somewhere in the middle. There will be a fixed version soon on my empeg page.

Stupid, stupid bug. And TERRIBLE parsing code. I just wanted something quick and dirty, and, well, it's dirty. In the meantime, if anyone gets a chance to try it, let me know if moving the empwake section fixes this.

I think the 8193 should be 8192 here:

iBytesRead = read( fdConfigIni, szConfigIni, 8193 );


I don't think so... Read just reads into a buffer, it doesn't add a null or anything like that... Why would I need the extra byte?

Yeah, I'm mixing printfs and fprintfs. I started using printf()'s at first and later realized I should really use to stderr for real errors. The printf's were placed in real quick to help narrow down this problem and will later be dropped. In fact all this parsing code is probably going to get a real overhaul soon.

Thanks, but I think in my above post I figured out the real problem. I wish the Empeg would drop core dumps somewhere, but I realize it'd need a nice r/w partition to do that. Oh well.

Okay guys give the new one a shot, at the usual place.

Where the hell is Bruno? He had this problem too.

Okay now that I worked the startup bug out of this thing, I spent a litle time tonight adding in a new feature. You can now set the alarm time in the current manner (absolute time) or as a "countdown timer" (relative time.) When you go to set the time in the "Time" menu, you can now select the "Set" label which has an equals sign or a plus sign next to it. Equals means the time you set is absolute, plus means it's relative to the current time. So now you can just say "fire the alarm in 8 hours" or whatever.

Still experimental, and I will probably need to tweak the UI, so all comments on this new feature are appreciated.

Not sure what else to add to this thing before I call it final. I was going to add a sleep timer like many alarm clocks have, but I don't think many people would use this feature, and there are problems making it and the regular alarm live happily together (namely the volumes would have to be raised and there are a lot of issues with how that would be done.)

The one thing this app *REALLY* needs is Mark Lord's in-place disk writing so I can save the time between reboots. I have no control over when that gets implemented, but you can expect a version of EmpWake to support it verhy soon thereafter.

Hope y'all like it. If I get favorable reviews on this one I'm going to post over in General where a lot more people read, and get this thing rolling towards a 1.0 release.

Any chance of implementing the 'time pips' every hour on the hour idea I had a while back?

this would be selectable, and a set time (every hour e.g X:59:56) it could play a FID
(which happened to be a set of timepips).

This would remind to switch over to my Radio/Tuner for the news if I wanted it.
Either that or it would remind its something O'clock, shouldn't I be where I need to go by now?

Cuckoo? Chimes? Big Ben?

The possibilities are endless.

Any chance of implementing the 'time pips' every hour on the hour idea I had a while back?

Well... It would be much easier for me to have it *beep* every hour (using the DSP's beeps) than it would be for me to have it actually play a FID or any kind of MP3 file. Well, let me clarify that... Surely I could have it play a FID every hour, but it would actually replace your playlist with that FID in the same way the alarm does. I don't think that's very desirable.

What I think would be much more useful is to be able to play that FID "mixed together" with current sound output, and that would require me to do my own MP3 decoding and mix the sounds, which means I'd have to figure out how the sound overlay patch works (I never had any luck with it last time.) Now, if these pre-recorded "pips" were WAV files, the step of MP3 decoding isn't necessary, but I'dstill have to figure out how to mix the sound outputs.

However, beeping using the DSP beep would be pretty simple to do, as the Empeg's mixer automatically handles mixing beeps and music. I'll add that to my list.

The next line of code is adding a null to the next byte:

szConfigIni[iBytesRead] = '\0';

Also, you could wrap the fprintf's in asserts, and leave them in there for debugging in the future.

Speedy

Ahh.. You're right, it should be 8192. That's actually why I chose the value 8193 for the buffer size, but then I forgot why I did it. That's not the bug I think people were tripping over, but it's a bug. I'll go fix that.

Yeah I plan on wrapping up the printf()'s in #ifdef's for a final release... I just put this thing together really quickly and the result looks unorganized. Exactly why I haven't released full source yet.

#define READSIZE 0x2000

wants to be your friend. Then you'd see that sizeof buffer is READSIZE+1, but the read is of READSIZE bytes.

Ah! Found it!!! (I think...)

I bet for those who are having this problem (Dragi and Bruno, among others) your [empwake] section is the *last* section in your config.ini.

Errr, I hate to tell you that, but it isn't. I'll give the new version a try in a moment...

No luck with 0.983, either. Identical behavior. However, I noticed that empwake unpacked from empwake-0.983.tar.gz (Apr 18 17:28 ) has modification date of Apr 16 08:00. Perhaps you packed an old version of the executable? Here are checksums:

empeg_masni:/tmp# cksum empwa*

49511689 130526 empwake

343311917 39992 empwake-0.98.tar.gz

3540631779 40101 empwake-0.981.tar.gz

1059658219 40784 empwake-0.983.tar.gz

Cheers!

Well, the modification date is off because my Linux box is, sadly, two days slow. It still says it's Tuesday. So I think you have the right file.

Does yours at least say "v0.983" when it starts up instead of 0.97 or 0.98? I've been updating the version string.

I think I'm going to junk this whole read from config.ini strategy in favor of command-line arguments real soon. This just isn't worth it... Would anyone have a problem passing in arguments instead of editing the config.ini?

Does yours at least say "v0.983" when it starts up instead of 0.97 or 0.98? I've been updating the version string.

Err, it does. Sorry, I wasn't looking carefully.

I think I'm going to junk this whole read from config.ini strategy in favor of command-line arguments real soon. This just isn't worth it... Would anyone have a problem passing in arguments instead of editing the config.ini?

Fine with me.

Thanks!

I think I'm going to junk this whole read from config.ini strategy in favor of command-line arguments real soon. This just isn't worth it... Would anyone have a problem passing in arguments instead of editing the config.ini?

Fine with me.

Well, I think the config.ini solution would be better. It just is the established place for configuring the empeg. And it is easily available via (j)emplode from almost any computer (because you can edit it via either serial, USB or ethernet), while any other place would only be available via either serial or Ethernet (with HiJack and/or telnetd installed).
I really think that any third party software that isn't storing all of its configuration in flash (and is fully configurable on the player itself) should store (additional) configuration options in config.ini.

cu,
sven

Well, I think the config.ini solution would be better.

Well obviously that was my preference going in, but it seems I've got some crossed gene in my DNA that makes me unable to find the bug in my parsing code that certain people are tripping over. EmpWake isn't going to have dozens of configurable options, so I figured the two or three that it does need could be passed in.

I don't know, maybe when I get back into town next week I'll try to re-write my parsing code and see if it fixes the problems. It'd be nice if Hijack had an ioctl to give you config options from config.ini, since it's already parsing it for its own use... Don't know how Mark would feel about that though.

First off, I am very grateful to all the programmers here for writing apps out of the goodness of their hearts. The community is one of the things that make the empeg as good as it is.
I know that you released the code for empwake, and when I get back home in a couple weeks, I intend to fool around with it myself. I just thought that I would mention in the meantime that I am experiencing the same thing as bruno and bonzi. I am not sure how many people this is affecting, but the program seems to stop just after I get the bytes read: XXX line. A crlf brings me back to the prompt, but the process is no longer running. Is this still an issue with others? or was there a work around? I know since the source is open I should try to figure it out myself rather than come here to ask about it, but I dont have access to a compiler till I get home and I am a little rusty in C to debug it from code without trying things.
Once again, thanks for your work on behalf of us out here who have not (yet) done our share.

Like I said, the next step for me is to make the options command-line arguments rather than config.ini options. That will probably happen whenever I get to porting my apps to the new graphics library. Can't say when that'll be, but I understand some people are having problems with this, it seems to be about 50% who have no problem and 50% who do. Moving options to the command-line will avoid my crappy parsing code.