search

Frosthaven / voicemeeter-windows-volume

Tray app that allows you to sync windows volume and mute state to Voicemeeter volume controls
303 stars 13 forks source link

script shuts itself down randomly #52

Open mashakos opened 9 months ago

mashakos commented 9 months ago

VMWV randomly exits (crashes?) in a pattern I cannot discern. My best guess is when I unplug my headphones, it exits. I basically have to run it from a shortcut every time I have my headphones on. Don't have anything more unfortunately, unless there is a method to generating log files I don't know about.

Jerrk commented 9 months ago

i would guess its the same issue as https://github.com/Frosthaven/voicemeeter-windows-volume/issues/39

do you have the "restart audio device on..." "audio device connection changes" option enabled? try turning that off and see if that fixes it for you

mashakos commented 9 months ago

it fixed it, kinda? VMWV no longer crashes which is great. only problem is that the fix negates one of the best features of the utility, which is auto detecting plugged in audio gear + restarting voicemeeter engine + tracking volume. Now I have to manually restart voicemeeter every time I plug in a pair of headphones

Jerrk commented 9 months ago

Yeah that is indeed a problem, just gotta wait for @Frosthaven to get some free time.

or if you're well-versed in javascript maybe you can create a pull request to fix the issue yourself.

XxLegitOPxX commented 4 months ago

I managed to somewhat fix this for myself by modifying the auto-start-task.ps1 script to also detect if VMWV would exit and automatically restart it.

  1. Go to where you installed VMWV and create a powershell script called auto-start-task-v2.ps1 containing the following: 
    
$scriptpath = $MyInvocation.MyCommand.Path
$dir = Split-Path $scriptpath
$vmwvPath = Join-Path $dir "required\VMWV.exe"
Set-Location $dir

function Start-VMWV {

Kill any existing VMWV processes

try {
    taskkill /im "VMWV.exe" /t /f
    Get-Process -Name "VMWV" -ErrorAction SilentlyContinue | Stop-Process -Force
} catch {}

# Start a fresh VMWV process
Start-Process -FilePath $vmwvPath -WindowStyle Hidden
# Wait for the process to start and become accessible
Start-Sleep -Seconds 2

$vmwv = Get-Process -Name "VMWV" -ErrorAction SilentlyContinue
while (-not $vmwv) {
    Start-Sleep -Seconds 1
    $vmwv = Get-Process -Name "VMWV" -ErrorAction SilentlyContinue
}

# Poll for child processes to ensure VMWV has access to cmd.exe
$polling_for_children = $true
$polling_count = 0
while ($polling_for_children) {
    $childProcesses = Get-WmiObject Win32_Process -Filter "ParentProcessId=$($vmwv.Id)"
    if ($childProcesses | Where-Object {$_.Name -eq "cmd.exe"}) {
        $polling_for_children = $false
        return $vmwv
    }

    $polling_count++
    if ($polling_count -gt 10) {
        $polling_for_children = $false
    }
    Start-Sleep -Seconds 1
}

return $null

}

Initial start

$vmwv = Start-VMWV

while ($true) { if (-not $vmwv) { Write-Host "VMWV failed to start, retrying..." $vmwv = Start-VMWV continue }

try {
    if ($vmwv.HasExited) {
        Write-Host "VMWV exited, restarting..."
        $vmwv = Start-VMWV
    }
} catch {
    Write-Host "Error checking VMWV process, restarting..."
    $vmwv = Start-VMWV
}

Start-Sleep -Seconds 5

}


2. Create a shortcut by rightclicking `auto-start-task-v2.ps1`, go to the shortcut's properties and add the following in the "Target" field (make sure you have the path below set to where *your* VMWV is installed, this is just where I installed it manually):

powershell.exe -ExecutionPolicy Bypass -WindowStyle Hidden -File "D:\Program Files (x86)\Voicemeeter Windows Volume\auto-start-task-v2.ps1"



3. (optional) Put the shortcut in a startup folder e.g. in `shell:common startup` (Win + R)

it's a bit hacky (and made partly with chatgpt) but it worked for me. hope this helps to anyone reading.
xizha127 commented 2 months ago 
powershell.exe -ExecutionPolicy Bypass -WindowStyle Hidden -File "D:\Program Files (x86)\Voicemeeter Windows Volume\auto-start-task-v2.ps1"
  1. (optional) Put the shortcut in a startup folder e.g. in shell:common startup (Win + R)

it's a bit hacky (and made partly with chatgpt) but it worked for me. hope this helps to anyone reading.

quick note that in this script it's "D:\" in the second part of the shortcut target, so if you're like me and have it installed in C: copy this target instead:

powershell.exe -ExecutionPolicy Bypass -WindowStyle Hidden -File "C:\Program Files (x86)\Voicemeeter Windows Volume\auto-start-task-v2.ps1"

sal0m0n commented 1 month ago

In my case, the issue was caused by insufficient permissions in the "required" folder. I resolved it by changing the folder's ownership to "Users" and granting "Full Control" permissions. After applying these changes, the application stopped crashing.

Here are the steps I followed:

This resolved the crash issue for me.

image

GraphicHealer commented 2 weeks ago

In my case, the issue was caused by insufficient permissions in the "required" folder. I resolved it by changing the folder's ownership to "Users" and granting "Full Control" permissions. After applying these changes, the application stopped crashing.

Here are the steps I followed:

  • Right-clicked on the "required" folder and selected Properties.
  • Went to the Security tab and clicked on Advanced.
  • Changed the owner to Users by clicking Change, entering "Users", and confirming, then clicked "Replace all child object permissions entries..." and Clicked Apply.
  • In the Security tab, clicked Edit, selected Users, and granted Full Control permissions.
  • Applied the changes to the folder and all its subfolders/files.

This resolved the crash issue for me.

image

Yeah, this did not work for me. It's running as admin, and admins AND users have been given full permissions to that folder, and it KEEPS crashing. I have to disable the Restart Audio Engine On... > Audio Device Connection Changes setting for it to keep running worth ANYTHING.

@Frosthaven Can we please have a fix for this? It's not exactly helpful when this app keeps crashing on one of it's most useful features.

GraphicHealer commented 1 week ago

Aha! I got a log output of the error!

PS C:\Program Files (x86)\Voicemeeter Windows Volume> & .\required\VMWV.exe
Voicemeeter Windows Volume started, Process ID:  56948
Using settings file: C:\Program Files (x86)\Voicemeeter Windows Volume\required\settings.json
Started Powershell worker "AudioDeviceScanner" with process ID of  75212
Started Powershell worker "StandbyScanner" with process ID of  73816
Enabling automatic start with Windows
Starting audio synchronization
Process found: voicemeeter8.exe
Voicemeeter: Fully Initialized
Started Powershell worker "AudioScanner" with process ID of  126188
Restaring audio engine. Reason: App Launch
Set initial volume to 50%
remembering volume: 50
remembering volume: 48
remembering volume: 50
remembering volume: 48
remembering volume: 50
remembering volume: 48
remembering volume: 50
remembering volume: 48
remembering volume: 50
remembering volume: 48
remembering volume: 50
remembering volume: 48
remembering volume: 50
Restaring audio engine. Reason: User Input
Driver Anomoly Detected: Volume reached 100% from 50%. Reverting to 50%
remembering volume: 100
remembering volume: 50
Driver Anomoly Detected: Volume reached 100% from 50%. Reverting to 50%
remembering volume: 100
remembering volume: 50
Driver Anomoly Detected: Volume reached 100% from 50%. Reverting to 50%
remembering volume: 100
remembering volume: 50
remembering volume: 48
remembering volume: 46
remembering volume: 48
remembering volume: 50
Exit Code: TypeError: Cannot read properties of undefined (reading 'magenta')
    at Timeout._onTimeout (C:\Program Files (x86)\Voicemeeter Windows Volume\required\webpack.bundle.js:1:29796)
    at listOnTimeout (node:internal/timers:559:17)
    at processTimers (node:internal/timers:502:7)
clean exit
PS C:\Program Files (x86)\Voicemeeter Windows Volume>
GraphicHealer commented 6 days ago

I think I found something, the only place magenta is mentioned is here: https://github.com/Frosthaven/voicemeeter-windows-volume/blob/9a60606e07c5cfca5652507207f2c6d4770477be/src/menuItems/restarts/itemRestartAudioEngineOnDeviceChange.js#L30-L38

It seems it's not checking if devices.old == null, and so every once in a while when it is null, it crashes as the chalk.magenta() function is trying to read a null value.

xizha127 commented 6 days ago

okay, seriously @GraphicHealer @sal0m0n.

There's no reason to really use this. Just get volume2, it has this built into it image

GraphicHealer commented 6 days ago

okay, seriously @GraphicHealer @sal0m0n.

There's no reason to really use this. Just get volume2, it has this built into it image

Yeah, except I don't see anything in Volume2 that automatically restarts Voicemeeter's backend when an audio device changes state. That's what this issue is about, not the volume knob. That works perfectly on VMWV.

What we are wanting is to not have to manually restart or re-connect audio devices to Voicemeeter when their state changes. VMWV does this well, when it's not broken.

xizha127 commented 6 days ago

oh, right. never had this issue, just let voicemeeter auto restart it's thing if it does

On Thu, Nov 21, 2024, 18:44 GraphicHealer @.***> wrote:

okay, seriously @GraphicHealer https://github.com/GraphicHealer @sal0m0n https://github.com/sal0m0n.

There's no reason to really use this. Just get volume2, it has this built into it [image: image] https://private-user-images.githubusercontent.com/147144945/388619926-1752c111-974b-4025-8b90-c57a176a2fa1.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MzIyMTA0MzcsIm5iZiI6MTczMjIxMDEzNywicGF0aCI6Ii8xNDcxNDQ5NDUvMzg4NjE5OTI2LTE3NTJjMTExLTk3NGItNDAyNS04YjkwLWM1N2ExNzZhMmZhMS5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjQxMTIxJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI0MTEyMVQxNzI4NTdaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT0xY2IwMjAyZWUyZDJkODRhYmE4YjY1ZmEzOWQyZmQ1Y2U3OWFjZmQ0ZWE2MGZkZjI2NTU1NTU2NmI5MGQ1NTc3JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.tTx_W7COepcTFNMQiA0oJ1GwlxpgHX9rp_m3nuVfKdk

Yeah, except I don't see anything in Volume2 that automatically restarts Voicemeeter's backend when an audio device changes state. That's what this issue is about, not the volume knob. That works perfectly on VMWV.

What we are wanting is to not have to manually restart or re-connect audio devices to Voicemeeter when their state changes. VMWV does this well, when it's not broken.

— Reply to this email directly, view it on GitHub https://github.com/Frosthaven/voicemeeter-windows-volume/issues/52#issuecomment-2491882922, or unsubscribe https://github.com/notifications/unsubscribe-auth/BDCUB4OIJOPM4YCNZOTGAVD2BYLXTAVCNFSM6AAAAABCYWD4VKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOJRHA4DEOJSGI . You are receiving this because you commented.Message ID: @.***>

GraphicHealer commented 6 days ago

oh, right. never had this issue, just let voicemeeter auto restart it's thing if it does

Yeah, except Voicemeeter only lets you select either output 1, or all, and if ANY of them are offline, it CONSTANTLY restarts.

VMWV gets around this by only restarting when the devices change states, and it lets you pick any combination of devices to monitor. It's much more flexible.