output notify?

Uhm, I have no clue what I did..

The past few weeks, while testing my external VFD, I've had the:
[output]
notify=1

in my config.ini file, like normal. The only thing that would get sent to the serial port is the boot-up messages, then my little program.

However, NOW (and again, I have no clue what I changed..) I get, every second:
serial_notify_thread.cpp: 180:@@ #5fe0 0:05:24

Now, ovciously, this completely screws up anything *I* wanted sent to the display. (On the other hand, it does "test" the VFD, which is what I wanted..)

But, how can I turn that BACK off? (Heck, for that matter, how'd I turn it ON?)

Thanks!
Me.

Put suppress_notify=1 into the hijack bit

Hijack normally suppresses the notify output, absorbing it all for internal use instead. If you just deleted Hijack, then that would explain why the messages suddenly began appearing..

Okay, that's effin' wierd. I haven't touched Hijack in a month, at least (was on 339). I just upgraded to 340 after the issue started happening. And it's still spitting out there...

I tried the other suggestion of adding the "supress_notify" option, to no effect..

This is why I hate computers.

Me.

[Edit: That's "suppress_notify" I found out. So, I changed it. No difference..]

Are you on/forced to AC maybe? The serial port assignment to applications vs the player in v336+ only works if you're on/forced to DC.

In reply to:

---

Are you on/forced to AC maybe? The serial port assignment to applications vs the player in v336+ only works if you're on/forced to DC.

---

What's strange is that it does it in AC or DC mode, and before, it NEVER did it in AC or DC mode. (Honest! I've been doing tests with my Empeg in the car and here at work, and never had this before..)

Huh! I forced it into DC mode to verift my Serial port usage..
My "Serial Port Assignment" was set on "App's Use Serial Port"; Which is what I set it for a long while ago.. But when I switched it to "Player Uses Serial Port" and rebooted, the messages stopped (however, could not get info from /proc/empeg_notify, either!).. Reboot into 'Normal' mode (in one of Mlord's docks), messages start. I'm wondering if some flash area got corrupted or something..

Me.

I'm getting this too. The notify messages aren't being suppressed. I have suppress_notify and played around with the Force DC and Serial Port Assignment options... What I want is to completely suppress these and only use them for /proc/empeg_notify. I have been having some occasional stuttering when in the car, and I think this might be the cause of it.

I'm getting this too. The notify messages aren't being suppressed.
(...)
I have been having some occasional stuttering when in the car, and I think this might be the cause of it.

Thanks for posting this. I am now suspcious that the problems with Tod's stalk interface (intermittent reception of serial commands, front panel controls sometimes locked out) might be caused by the same thing. We also put suppress_notify in there in hopes of solving the problem and it didn't.

Sure would be nice if we didn't have to dig into his dash to work on wiring again.

We await the word of The Lord.

What settings do I need to use to reproduce this?

I never see car player notify messages when I have

[hijack]
suppress_notify=1

??????????????????

Here's my hijack section:

[hijack]

suppress_notify=1

menu_remove=Button Illumination Level

menu_remove=Calculator

;@EXEC_ONCE /usr/local/bin/emphatic

temperature_correction=-4             ;default value shown (degrees C)

kftpd_control_port=21

kftpd_data_port=20

khttpd_port=80

khttpd_root_index=/drive0/opt/khttpd/charcoalgray99/index.html

PopUp1=Tweak...

disable_bassboost_FM=1

;volume_boost_FM=-2

;volume_boost_AM=-5

standbyLED_on=0         ;; in 1/100ths of a second

standbyLED_off=1000     ;; in 1/100ths of a second

overlay_bg_min=0x00003000;

overlay_bg_max=0x00010000;

overlay_bg_fadestep=0x00001000;

.
And my output section:

[output]          

notify=1

.

What else could be different?

AC /DC ? Real or forced? Docked or undocked? Serial port player or app? Fresh power on or reboot? ...

"Real" (not forced) AC in one of your docks. I suspect it's also happening in the car but can't verify because I don't have a laptop to read the serial.

The reason I looked into this was some stuttering/hiccups during playback that started happening since I upgraded Hijack (I think I was at v340 before.) I just flashed back to v340 and the messages disappear, so I suspect this might be related to something you've done between v340 and v344. Any ideas?

Bump... Any ideas, Mark?

Nope, no ideas.

Unless maybe you are running v3alpha3 software?

Unless maybe you are running v3alpha3 software?

Yes...

Mm.. Okay, I just reinstalled v3a3 on a player here, and suppress_notify=0 allows the player output to the serial port, and removing that line from config.ini prevents the player's output to serial. Works normally.

??

Try it again without Emphatic or any other EXEC lines..

Hmm. Taking emphatic out didn't change anything, but I downloaded a v344 kernel from your site (instead of using my v344 source tree) and the messages are gone.

The weird part is I started out with a v300 kernel tree from your site (v300.tar.bz2) and ran all of the incremental patches from v300-v301 to v343-v344. So it *should* be the same thing as you have in the v344 image. I just did it again with the same results... So somehow, the kernel I'm getting by applying all of your patches to the v300 tree is different than the kernels you're releasing.

I guess I'll just have to use the prebuilt kernels until I can figure it out.

There may be tiny differences.. can you run a recursive "diff -u" on the two directories (after doing "make mrproper" on each) and send me the results?

Thanks

Which two directories? Are you asking me to compare a virgin v300 tree to the v344 tree I obtained by applying all the incrementals?

No, just compare the v344 that you were building from with a virgin v344 -- grab v342.tar.bz2 from the Hijack site, and apply the two extra patches to convert it into v344, then diff it against the one that you were using before.

Cheers

Okay, this is just absurd now. I did the diff and other than the presence of hijack.c.orig in one of the trees and not the other, there were no other differences.

To prove I'm not insane, I built kernels out of both trees. The one built from the v300+42 patches tree gives me notify output, the one built from the v342+2patches tree doesn't give me notify output. In both cases, all I did after running the patches was copy arch/arm/defconfig to .config, make config, and make zImage.

The mystery then becomes how two identical source trees (or at least identical according to "diff -u --recursive --new-file --exclude=zImage --exclude=config.ini --exclude=.* --exclude=*.patch --exclude=buildit --exclude=defconfig --exclude=hijack.c.orig v300 v342") can yield two different kernels. I'm calling Unsolved Mysteries on that one.

When I built v342 by patching, and compared to v342 as downloaded, I noticed this. I doubt it's significant, but I'm curious how these options were set in the kernel you built yourself?

--- v1-/arch/arm/defconfig Thu Oct 9 16:34:34 2003
+++ v342/arch/arm/defconfig Thu Jun 12 12:55:21 2003
@@ -129,6 +129,8 @@
# CONFIG_EMPEG_DISPLAY_INVERTED is not set
CONFIG_EMPEG_POWER=y
# CONFIG_EMPEG_RAMTEST is not set
+CONFIG_EMPEG_I2C_FAN_CONTROL=y
+CONFIG_HIJACK_TUNER=y

#
# Video For Linux
@@ -200,7 +202,7 @@
# IrDA protocols
#
# CONFIG_IRLAN is not set
-CONFIG_IRCOMM=y
+# CONFIG_IRCOMM is not set
# CONFIG_IRDA_ULTRA is not set
# CONFIG_IRDA_OPTIONS is not set
# CONFIG_IRDA_COMPRESSION is not set